profile
viewpoint

pull request commentrust-lang/rust

expand osx sanitizer support (lsan, dylib, cdylib, staticlib)

@gnzlbg I'm up for writing some docs on the sanitizers, but I think it should be in a separate PR so folks can chime in with their experiences. I am only familiar with using the sanitizers on macos. On macos you have to dynamically link to the sanitizers - which mostly comes when building a dylib, cdylib, or staticlib. The most annoying thing IMO is that if you have any proc-macro dependencies then the target has to be explicit.

$ RUSTFLAGS="-Zsanitizer=address" cargo run # error
$ RUSTFLAGS="-Zsanitizer=address" cargo run --target x86_64-apple-darwin # ok

I often find it tricky to enable msan, often needing to use #![no_std] binaries for that.

The sanitizer code on master should error out for no_std as best I can tell. What sorts of problems were you getting without #![no_std]? The sanitizers (before this PR) would conditionally be added as an Explicit dependency, which is different from all the other injected dependencies. Perhaps that is related to needing #![no_std]? I think this was done so that the sanitizer's code would be statically linked in to staticlib/dylib/cdylibs. This PR attempts to link the sanitizer code in using the activate_injected_dep codepath instead of Explicit deps, however I have no idea if that works, or gives better results - unable to test on macos due to always dynamically linking the sanitizers.

mtak-

comment created time in a few seconds

pull request commentrust-lang/rust

Add binary dependencies to dep-info files

It might be rather hard for me to debug since I don't have easy access to windows

I often use the free VMs from microsoft when I'm not near a windows machine.

I added a hack to my Cargo PR to deal with the extended-length paths. I don't have much of an opinion on it, but I'd be curious if there are any other consumers of the .d files besides Cargo. That might influence your decision on which style to expose, if other tools have problems with mixing them.

Mark-Simulacrum

comment created time in 9 minutes

Pull request review commentrust-lang/rust

[WIP] Elide allocation of uninit static

 pub struct Allocation<Tag=(),Extra=()> {     pub extra: Extra, } +#[derive(Clone, Debug, Eq, PartialEq, PartialOrd, Ord, Hash, RustcEncodable, RustcDecodable)]+pub struct AllocationBytes {+    /// The actual bytes of the allocation.+    /// Note that the bytes of a pointer represent the offset of the pointer+    pub bytes: Vec<u8>,+    /// Denotes undefined memory. Reading from undefined memory is forbidden in miri+    pub undef_mask: UndefMask,+}++pub enum BytesOrElidedUndef<'a> {+    /// Some bytes that may be undef but were not elided.+    MaybeBytes(&'a [u8]),+    /// An undef that has never been written to and was not yet allocated.+    ElidedUndef,+}

It will have to be its own type if the compiler were to adopt the optimization for constant values such as 'zeroed' as well. I'm not sure if that is a very good argument in support or if this should prepare such a future change.

HeroicKatora

comment created time in 9 minutes

pull request commentrust-lang/crates.io

Support Cirrus CI badges

:pushpin: Commit a7c8fc7c5578ad7c7007cd4acb562ffe449aa389 has been approved by sgrif

<!-- @bors r=sgrif a7c8fc7c5578ad7c7007cd4acb562ffe449aa389 --> <!-- homu: {"type":"Approved","sha":"a7c8fc7c5578ad7c7007cd4acb562ffe449aa389","approver":"sgrif"} -->

jonhoo

comment created time in 9 minutes

pull request commentrust-lang/crates.io

Support Cirrus CI badges

@bors: r+

Can you open a PR to Cargo updating the docs for this in https://github.com/rust-lang/cargo/blob/master/src/doc/src/reference/manifest.md as well?

jonhoo

comment created time in 9 minutes

pull request commentrust-lang/crates.io

Fix checks and consistency in the API endpoints to manage ownership.

:pushpin: Commit 794cc87948a990525d0959249755ac9d10ea12ae has been approved by sgrif

<!-- @bors r=sgrif 794cc87948a990525d0959249755ac9d10ea12ae --> <!-- homu: {"type":"Approved","sha":"794cc87948a990525d0959249755ac9d10ea12ae","approver":"sgrif"} -->

smarnach

comment created time in 13 minutes

pull request commentrust-lang/crates.io

Switch back to released versions of `lettre` and `lettre_email`

:pushpin: Commit 8ba85ac7682c1deeca673da6f02f48b82fa9fde3 has been approved by sgrif

<!-- @bors r=sgrif 8ba85ac7682c1deeca673da6f02f48b82fa9fde3 --> <!-- homu: {"type":"Approved","sha":"8ba85ac7682c1deeca673da6f02f48b82fa9fde3","approver":"sgrif"} -->

jtgeibel

comment created time in 13 minutes

push eventrust-lang/crates.io

Sven Marnach

commit sha a009846991fd3d7614bbe0d5acb2d77d273e6480

Factor out request body parsing to separate function.

view details

Sven Marnach

commit sha 055df9b0b74ec93718921d81a66af023158a2bf2

Wrap owner modification endpoints in database transaction.

view details

Sven Marnach

commit sha 7ebcfe752b92623d527f9f614e59d540cb9e73e0

Fix owner removal check.

view details

Sven Marnach

commit sha 10851f36dc651fadcafa2f7b9843f7963eb79045

Merge remote-tracking branch 'origin' into fix-owner-checks

view details

Sven Marnach

commit sha 794cc87948a990525d0959249755ac9d10ea12ae

Use `json!` macro instead of `format!` in tests.

view details

bors

commit sha 2a036e552c611240628b4ebdd0bbd337bdee9389

Auto merge of #1772 - smarnach:fix-owner-checks, r=sgrif Fix checks and consistency in the API endpoints to manage ownership. Fixes #1583. The API endpoints to add and remove owners for a crate has multiple issues. * The database interactions are not wrapped in a transaction, making them prone to race conditions. * The lack of a transaction can also result in partially applied operations, e.g. when adding or removing multiple owners at once. * The check whether the last owner was removed only triggers if the _original_ list of owners had a length of exactly one. This is wrong in at least two cases: * Teams do not have permission to manage ownership, so they should not be counted. * If multiple users are removed at once, we can end up with no owners even when there originally was more than one user. This change fixes all mentioned problems, and adds tests for all bullet points except for the first one (which can't be tested with reasonable effort).

view details

push time in 13 minutes

pull request commentrust-lang/crates.io

Switch back to released versions of `lettre` and `lettre_email`

@bors: r+

jtgeibel

comment created time in 13 minutes

pull request commentrust-lang/crates.io

Fix checks and consistency in the API endpoints to manage ownership.

:hourglass: Testing commit 794cc87948a990525d0959249755ac9d10ea12ae with merge 2a036e552c611240628b4ebdd0bbd337bdee9389... <!-- homu: {"type":"BuildStarted","head_sha":"794cc87948a990525d0959249755ac9d10ea12ae","merge_sha":"2a036e552c611240628b4ebdd0bbd337bdee9389"} -->

smarnach

comment created time in 13 minutes

pull request commentrust-lang/crates.io

Fix checks and consistency in the API endpoints to manage ownership.

@bors: r+

smarnach

comment created time in 13 minutes

Pull request review commentrust-lang/rust

[WIP] Elide allocation of uninit static

 use std::borrow::Cow;  #[derive(Clone, Debug, Eq, PartialEq, PartialOrd, Ord, Hash, RustcEncodable, RustcDecodable)] pub struct Allocation<Tag=(),Extra=()> {-    /// The actual bytes of the allocation.-    /// Note that the bytes of a pointer represent the offset of the pointer-    pub bytes: Vec<u8>,+    /// The byte allocation and definedness.+    /// Bytes of fully undefined allocations are allocated lazily on potentially mutable changes.

It's always allocated within get_bytes_mut but I hadn't realized that the method also marks the bytes as defined when I had written that comment. Good catch.

HeroicKatora

comment created time in 14 minutes

pull request commentrust-lang/rust

[WIP] Place 2.0 change from enum to struct

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

<details><summary><i>Click to expand the log.</i></summary>

2019-07-16T17:44:47.7878045Z ##[command]git remote add origin https://github.com/rust-lang/rust
2019-07-16T17:44:47.8077229Z ##[command]git config gc.auto 0
2019-07-16T17:44:47.8146846Z ##[command]git config --get-all http.https://github.com/rust-lang/rust.extraheader
2019-07-16T17:44:47.8208596Z ##[command]git config --get-all http.proxy
2019-07-16T17:44:47.8350558Z ##[command]git -c http.extraheader="AUTHORIZATION: basic ***" fetch --force --tags --prune --progress --no-recurse-submodules --depth=2 origin +refs/heads/*:refs/remotes/origin/* +refs/pull/60913/merge:refs/remotes/pull/60913/merge
---
2019-07-16T17:45:23.4586983Z do so (now or later) by using -b with the checkout command again. Example:
2019-07-16T17:45:23.4587017Z 
2019-07-16T17:45:23.4588225Z   git checkout -b <new-branch-name>
2019-07-16T17:45:23.4588259Z 
2019-07-16T17:45:23.4588338Z HEAD is now at 86d68d560 Merge 04909eb2269ddb917926c068583bffda06f24743 into d36b7f69448f7390fa9dfde75d58b914365acdab
2019-07-16T17:45:23.4742501Z ##[section]Starting: Collect CPU-usage statistics in the background
2019-07-16T17:45:23.4746698Z ==============================================================================
2019-07-16T17:45:23.4746764Z Task         : Bash
2019-07-16T17:45:23.4746832Z Description  : Run a Bash script on macOS, Linux, or Windows
---
2019-07-16T17:47:14.6972744Z Attempting with retry: curl -y 30 -Y 10 --connect-timeout 30 -f -L -C - -o /tmp/rustci_docker_cache https://.s3.amazonaws.com/docker/a4940e6914a5e1f6360ebc241d0d850aff083be5c43d268fd716ce48f63cb24e84238becb662f27f8c5d7740413ca17da24bb9cdc003ef32d7b03d2c9052b94d
2019-07-16T17:47:14.7041878Z   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
2019-07-16T17:47:14.7042303Z                                  Dload  Upload   Total   Spent    Left  Speed
2019-07-16T17:47:14.7051057Z 
2019-07-16T17:47:14.7085680Z   0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0curl: (6) Could not resolve host: .s3.amazonaws.com
2019-07-16T17:47:15.7182351Z   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
2019-07-16T17:47:15.7182496Z                                  Dload  Upload   Total   Spent    Left  Speed
2019-07-16T17:47:15.7182600Z 
2019-07-16T17:47:15.7182600Z 
2019-07-16T17:47:15.7183656Z   0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0curl: (6) Could not resolve host: .s3.amazonaws.com
2019-07-16T17:47:17.7253644Z   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
2019-07-16T17:47:17.7254047Z                                  Dload  Upload   Total   Spent    Left  Speed
2019-07-16T17:47:17.7254239Z 
2019-07-16T17:47:17.7254239Z 
2019-07-16T17:47:17.7295488Z   0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0curl: (6) Could not resolve host: .s3.amazonaws.com
2019-07-16T17:47:20.7369578Z   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
2019-07-16T17:47:20.7369747Z                                  Dload  Upload   Total   Spent    Left  Speed
2019-07-16T17:47:20.7369895Z 
2019-07-16T17:47:20.7369895Z 
2019-07-16T17:47:20.7412580Z   0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0curl: (6) Could not resolve host: .s3.amazonaws.com
2019-07-16T17:47:24.7505718Z   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
2019-07-16T17:47:24.7509143Z                                  Dload  Upload   Total   Spent    Left  Speed
2019-07-16T17:47:24.7509453Z 
2019-07-16T17:47:24.7509453Z 
2019-07-16T17:47:24.7511828Z   0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0curl: (6) Could not resolve host: .s3.amazonaws.com
2019-07-16T17:47:24.7516626Z The command has failed after 5 attempts.
2019-07-16T17:47:24.8061747Z open /tmp/rustci_docker_cache: no such file or directory
2019-07-16T17:47:24.8086216Z Attempting with retry: docker build --rm -t rust-ci -f /home/vsts/work/1/s/src/ci/docker/mingw-check/Dockerfile /home/vsts/work/1/s/src/ci/docker
2019-07-16T17:47:25.0483437Z Sending build context to Docker daemon  521.7kB
2019-07-16T17:47:25.0484450Z 
2019-07-16T17:47:25.0665839Z Step 1/6 : FROM ubuntu:16.04
---
2019-07-16T17:47:40.1422763Z Reading package lists...
2019-07-16T17:47:41.1701344Z Reading package lists...
2019-07-16T17:47:41.3611604Z Building dependency tree...
2019-07-16T17:47:41.3611712Z Reading state information...
2019-07-16T17:47:41.4751681Z The following additional packages will be installed:
2019-07-16T17:47:41.4752497Z   binutils binutils-mingw-w64-i686 binutils-mingw-w64-x86-64 bzip2 cmake-data
2019-07-16T17:47:41.4753275Z   cpp cpp-5 dpkg-dev g++-5 g++-mingw-w64 g++-mingw-w64-i686
2019-07-16T17:47:41.4753598Z   g++-mingw-w64-x86-64 gcc gcc-5 gcc-mingw-w64 gcc-mingw-w64-base
2019-07-16T17:47:41.4753853Z   gcc-mingw-w64-i686 gcc-mingw-w64-x86-64 git-man libarchive13 libasan2
2019-07-16T17:47:41.4754101Z   libasn1-8-heimdal libatomic1 libbabeltrace-ctf1 libbabeltrace1 libbz2-1.0
2019-07-16T17:47:41.4754649Z   libdpkg-perl liberror-perl libexpat1 libffi6 libgcc-5-dev libgdbm3
2019-07-16T17:47:41.4754898Z   libglib2.0-0 libgmp10 libgnutls30 libgomp1 libgssapi-krb5-2
2019-07-16T17:47:41.4755188Z   libgssapi3-heimdal libhcrypto4-heimdal libheimbase1-heimdal
2019-07-16T17:47:41.4755433Z   libheimntlm0-heimdal libhogweed4 libhx509-5-heimdal libicu55 libidn11
2019-07-16T17:47:41.4755433Z   libheimntlm0-heimdal libhogweed4 libhx509-5-heimdal libicu55 libidn11
2019-07-16T17:47:41.4755680Z   libisl15 libitm1 libjsoncpp1 libk5crypto3 libkeyutils1 libkrb5-26-heimdal
2019-07-16T17:47:41.4755981Z   libkrb5-3 libkrb5support0 libldap-2.4-2 liblsan0 liblzo2-2 libmagic1 libmpc3
2019-07-16T17:47:41.4756231Z   libmpdec2 libmpfr4 libmpx0 libnettle6 libp11-kit0 libperl5.22
2019-07-16T17:47:41.4756477Z   libpython2.7-minimal libpython2.7-stdlib libpython3.5 libpython3.5-minimal
2019-07-16T17:47:41.4756773Z   libpython3.5-stdlib libquadmath0 libroken18-heimdal librtmp1 libsasl2-2
2019-07-16T17:47:41.4757017Z   libsasl2-modules-db libsqlite3-0 libssl1.0.0 libstdc++-5-dev libtasn1-6
2019-07-16T17:47:41.4757259Z   libtsan0 libubsan0 libwind0-heimdal libxml2 linux-libc-dev mime-support
2019-07-16T17:47:41.4757570Z   mingw-w64-common mingw-w64-i686-dev mingw-w64-x86-64-dev openssl patch perl
2019-07-16T17:47:41.4758539Z   perl-modules-5.22 python2.7-minimal zlib1g-dev
2019-07-16T17:47:41.4758639Z Suggested packages:
2019-07-16T17:47:41.4759983Z   binutils-doc bzip2-doc codeblocks eclipse ninja-build cpp-doc gcc-5-locales
2019-07-16T17:47:41.4760263Z   debian-keyring g++-multilib g++-5-multilib gcc-5-doc libstdc++6-5-dbg
2019-07-16T17:47:41.4760517Z   gcc-multilib manpages-dev autoconf automake libtool flex bison gcc-doc
2019-07-16T17:47:41.4761109Z   libasan2-dbg liblsan0-dbg libtsan0-dbg libubsan0-dbg libcilkrts5-dbg
2019-07-16T17:47:41.4761359Z   libmpx0-dbg libquadmath0-dbg gdb-doc gettext-base git-daemon-run
2019-07-16T17:47:41.4761359Z   libmpx0-dbg libquadmath0-dbg gdb-doc gettext-base git-daemon-run
2019-07-16T17:47:41.4761661Z   | git-daemon-sysvinit git-doc git-el git-email git-gui gitk gitweb git-arch
2019-07-16T17:47:41.4761924Z   git-cvs git-mediawiki git-svn lrzip glibc-doc gnutls-bin krb5-doc krb5-user
2019-07-16T17:47:41.4762179Z   libstdc++-5-doc make-doc wine wine64 ed diffutils-doc perl-doc
2019-07-16T17:47:41.4762475Z   libterm-readline-gnu-perl | libterm-readline-perl-perl python2.7-doc
2019-07-16T17:47:41.4762680Z   binfmt-support
2019-07-16T17:47:41.4762728Z Recommended packages:
2019-07-16T17:47:41.4763171Z   build-essential fakeroot libalgorithm-merge-perl gfortran-mingw-w64
2019-07-16T17:47:41.4763415Z   gnat-mingw-w64 libc-dbg gdbserver less rsync ssh-client manpages
2019-07-16T17:47:41.4763664Z   manpages-dev libfile-fcntllock-perl libglib2.0-data shared-mime-info
2019-07-16T17:47:41.4763952Z   xdg-user-dirs krb5-locales libsasl2-modules libssl-doc xml-core netbase
2019-07-16T17:47:41.4764004Z   rename
2019-07-16T17:47:41.4780840Z The following NEW packages will be installed:
2019-07-16T17:47:41.4781397Z   binutils binutils-mingw-w64-i686 binutils-mingw-w64-x86-64 bzip2
2019-07-16T17:47:41.4781735Z   ca-certificates cmake cmake-data cpp cpp-5 curl dpkg-dev file g++ g++-5
2019-07-16T17:47:41.4782571Z   g++-mingw-w64 g++-mingw-w64-i686 g++-mingw-w64-x86-64 gcc gcc-5
2019-07-16T17:47:41.4783054Z   gcc-mingw-w64 gcc-mingw-w64-base gcc-mingw-w64-i686 gcc-mingw-w64-x86-64 gdb
2019-07-16T17:47:41.4783344Z   git git-man libarchive13 libasan2 libasn1-8-heimdal libatomic1
2019-07-16T17:47:41.4783586Z   libbabeltrace-ctf1 libbabeltrace1 libc-dev-bin libc6-dev libcc1-0
2019-07-16T17:47:41.4784219Z   libffi6 libgcc-5-dev libgdbm3 libglib2.0-0 libgmp10 libgnutls30 libgomp1
2019-07-16T17:47:41.4784472Z   libgssapi-krb5-2 libgssapi3-heimdal libhcrypto4-heimdal libheimbase1-heimdal
2019-07-16T17:47:41.4784709Z   libheimntlm0-heimdal libhogweed4 libhx509-5-heimdal libicu55 libidn11
2019-07-16T17:47:41.4785354Z   libisl15 libitm1 libjsoncpp1 libk5crypto3 libkeyutils1 libkrb5-26-heimdal
2019-07-16T17:47:41.4785354Z   libisl15 libitm1 libjsoncpp1 libk5crypto3 libkeyutils1 libkrb5-26-heimdal
2019-07-16T17:47:41.4785764Z   libkrb5-3 libkrb5support0 libldap-2.4-2 liblsan0 liblzo2-2 libmagic1 libmpc3
2019-07-16T17:47:41.4785996Z   libmpdec2 libmpfr4 libmpx0 libnettle6 libp11-kit0 libperl5.22
2019-07-16T17:47:41.4786458Z   libpython2.7-minimal libpython2.7-stdlib libpython3.5 libpython3.5-minimal
2019-07-16T17:47:41.4787232Z   libpython3.5-stdlib libquadmath0 libroken18-heimdal librtmp1 libsasl2-2
2019-07-16T17:47:41.4787459Z   libsasl2-modules-db libsqlite3-0 libssl-dev libssl1.0.0 libstdc++-5-dev
2019-07-16T17:47:41.4787729Z   libtasn1-6 libtsan0 libubsan0 libwind0-heimdal libxml2 linux-libc-dev make
2019-07-16T17:47:41.4787971Z   mime-support mingw-w64 mingw-w64-common mingw-w64-i686-dev
2019-07-16T17:47:41.4788196Z   mingw-w64-x86-64-dev openssl patch perl perl-modules-5.22 pkg-config
2019-07-16T17:47:41.4788448Z   python2.7 python2.7-minimal sudo xz-utils zlib1g-dev
2019-07-16T17:47:41.4788500Z The following packages will be upgraded:
2019-07-16T17:47:41.7858808Z 1 upgraded, 112 newly installed, 0 to remove and 5 not upgraded.
2019-07-16T17:47:41.7859008Z Need to get 187 MB of archives.
2019-07-16T17:47:41.7859090Z After this operation, 968 MB of additional disk space will be used.
2019-07-16T17:47:41.7863210Z Get:1 http://archive.ubuntu.com/ubuntu xenial/main amd64 libgdbm3 amd64 1.8.3-13.1 [16.9 kB]
---
2019-07-16T17:47:43.2563295Z Get:97 http://archive.ubuntu.com/ubuntu xenial-updates/main amd64 zlib1g-dev amd64 1:1.2.8.dfsg-2ubuntu4.1 [168 kB]
2019-07-16T17:47:43.2586632Z Get:98 http://archive.ubuntu.com/ubuntu xenial-updates/main amd64 libssl-dev amd64 1.0.2g-1ubuntu4.15 [1344 kB]
2019-07-16T17:47:43.3700873Z Get:99 http://archive.ubuntu.com/ubuntu xenial/main amd64 pkg-config amd64 0.29.1-0ubuntu1 [45.0 kB]
2019-07-16T17:47:43.3703417Z Get:100 http://archive.ubuntu.com/ubuntu xenial-updates/main amd64 python2.7 amd64 2.7.12-1ubuntu0~16.04.4 [224 kB]
2019-07-16T17:47:43.3744210Z Get:101 http://archive.ubuntu.com/ubuntu xenial/universe amd64 binutils-mingw-w64-i686 amd64 2.26-3ubuntu1+6.6 [1782 kB]
2019-07-16T17:47:43.4517538Z Get:102 http://archive.ubuntu.com/ubuntu xenial/universe amd64 binutils-mingw-w64-x86-64 amd64 2.26-3ubuntu1+6.6 [2029 kB]
2019-07-16T17:47:43.6882776Z Get:103 http://archive.ubuntu.com/ubuntu xenial/universe amd64 mingw-w64-common all 4.0.4-2 [4787 kB]
2019-07-16T17:47:43.7582259Z Get:104 http://archive.ubuntu.com/ubuntu xenial/universe amd64 mingw-w64-i686-dev all 4.0.4-2 [2059 kB]
2019-07-16T17:47:43.7890913Z Get:105 http://archive.ubuntu.com/ubuntu xenial/universe amd64 gcc-mingw-w64-base amd64 5.3.1-8ubuntu3+17 [11.2 kB]
2019-07-16T17:47:43.7896227Z Get:106 http://archive.ubuntu.com/ubuntu xenial/universe amd64 gcc-mingw-w64-i686 amd64 5.3.1-8ubuntu3+17 [27.3 MB]
2019-07-16T17:47:44.2030624Z Get:107 http://archive.ubuntu.com/ubuntu xenial/universe amd64 g++-mingw-w64-i686 amd64 5.3.1-8ubuntu3+17 [19.8 MB]
2019-07-16T17:47:44.4898667Z Get:108 http://archive.ubuntu.com/ubuntu xenial/universe amd64 mingw-w64-x86-64-dev all 4.0.4-2 [3238 kB]
2019-07-16T17:47:44.5378360Z Get:109 http://archive.ubuntu.com/ubuntu xenial/universe amd64 gcc-mingw-w64-x86-64 amd64 5.3.1-8ubuntu3+17 [27.4 MB]
2019-07-16T17:47:44.9334215Z Get:110 http://archive.ubuntu.com/ubuntu xenial/universe amd64 g++-mingw-w64-x86-64 amd64 5.3.1-8ubuntu3+17 [20.4 MB]
2019-07-16T17:47:45.2601710Z Get:111 http://archive.ubuntu.com/ubuntu xenial/universe amd64 g++-mingw-w64 all 5.3.1-8ubuntu3+17 [10.7 kB]
2019-07-16T17:47:45.2603861Z Get:112 http://archive.ubuntu.com/ubuntu xenial/universe amd64 gcc-mingw-w64 all 5.3.1-8ubuntu3+17 [10.7 kB]
2019-07-16T17:47:45.2608589Z Get:113 http://archive.ubuntu.com/ubuntu xenial/universe amd64 mingw-w64 all 4.0.4-2 [9274 B]
2019-07-16T17:47:47.6034517Z debconf: delaying package configuration, since apt-utils is not installed
2019-07-16T17:47:47.6288103Z Fetched 187 MB in 3s (53.0 MB/s)
2019-07-16T17:47:47.6870043Z (Reading database ... 
2019-07-16T17:47:47.6870446Z (Reading database ... 5%
2019-07-16T17:47:47.6870709Z (Reading database ... 10%
2019-07-16T17:47:47.6870986Z (Reading database ... 15%
---
2019-07-16T17:48:10.5882699Z Unpacking git (1:2.7.4-0ubuntu1.6) ...
2019-07-16T17:48:11.3504067Z Selecting previously unselected package libpython2.7-stdlib:amd64.
2019-07-16T17:48:11.3522117Z Preparing to unpack .../libpython2.7-stdlib_2.7.12-1ubuntu0~16.04.4_amd64.deb ...
2019-07-16T17:48:11.3675716Z Unpacking libpython2.7-stdlib:amd64 (2.7.12-1ubuntu0~16.04.4) ...
2019-07-16T17:48:11.7246388Z Selecting previously unselected package zlib1g-dev:amd64.
2019-07-16T17:48:11.7260892Z Preparing to unpack .../zlib1g-dev_1%3a1.2.8.dfsg-2ubuntu4.1_amd64.deb ...
2019-07-16T17:48:11.7377747Z Unpacking zlib1g-dev:amd64 (1:1.2.8.dfsg-2ubuntu4.1) ...
2019-07-16T17:48:11.8437000Z Preparing to unpack .../libssl-dev_1.0.2g-1ubuntu4.15_amd64.deb ...
2019-07-16T17:48:11.8555455Z Unpacking libssl-dev:amd64 (1.0.2g-1ubuntu4.15) ...
2019-07-16T17:48:12.6666119Z Selecting previously unselected package pkg-config.
2019-07-16T17:48:12.6684153Z Preparing to unpack .../pkg-config_0.29.1-0ubuntu1_amd64.deb ...
2019-07-16T17:48:12.6684153Z Preparing to unpack .../pkg-config_0.29.1-0ubuntu1_amd64.deb ...
2019-07-16T17:48:12.6796824Z Unpacking pkg-config (0.29.1-0ubuntu1) ...
2019-07-16T17:48:12.7709816Z Selecting previously unselected package python2.7.
2019-07-16T17:48:12.7732270Z Preparing to unpack .../python2.7_2.7.12-1ubuntu0~16.04.4_amd64.deb ...
2019-07-16T17:48:12.7851062Z Unpacking python2.7 (2.7.12-1ubuntu0~16.04.4) ...
2019-07-16T17:48:12.8743081Z Selecting previously unselected package binutils-mingw-w64-i686.
2019-07-16T17:48:12.8765755Z Preparing to unpack .../binutils-mingw-w64-i686_2.26-3ubuntu1+6.6_amd64.deb ...
2019-07-16T17:48:12.8892326Z Unpacking binutils-mingw-w64-i686 (2.26-3ubuntu1+6.6) ...
2019-07-16T17:48:13.4182985Z Selecting previously unselected package binutils-mingw-w64-x86-64.
2019-07-16T17:48:13.4199413Z Preparing to unpack .../binutils-mingw-w64-x86-64_2.26-3ubuntu1+6.6_amd64.deb ...
2019-07-16T17:48:13.4326884Z Unpacking binutils-mingw-w64-x86-64 (2.26-3ubuntu1+6.6) ...
2019-07-16T17:48:14.0545212Z Selecting previously unselected package mingw-w64-common.
2019-07-16T17:48:14.0565013Z Preparing to unpack .../mingw-w64-common_4.0.4-2_all.deb ...
2019-07-16T17:48:14.0685023Z Unpacking mingw-w64-common (4.0.4-2) ...
2019-07-16T17:48:15.5109063Z Selecting previously unselected package mingw-w64-i686-dev.
2019-07-16T17:48:15.5131454Z Preparing to unpack .../mingw-w64-i686-dev_4.0.4-2_all.deb ...
2019-07-16T17:48:15.5250718Z Unpacking mingw-w64-i686-dev (4.0.4-2) ...
2019-07-16T17:48:16.6760820Z Selecting previously unselected package gcc-mingw-w64-base.
2019-07-16T17:48:16.6793351Z Preparing to unpack .../gcc-mingw-w64-base_5.3.1-8ubuntu3+17_amd64.deb ...
2019-07-16T17:48:16.6939257Z Unpacking gcc-mingw-w64-base (5.3.1-8ubuntu3+17) ...
2019-07-16T17:48:16.7884201Z Selecting previously unselected package gcc-mingw-w64-i686.
2019-07-16T17:48:16.7908286Z Preparing to unpack .../gcc-mingw-w64-i686_5.3.1-8ubuntu3+17_amd64.deb ...
2019-07-16T17:48:16.8031135Z Unpacking gcc-mingw-w64-i686 (5.3.1-8ubuntu3+17) ...
2019-07-16T17:48:21.1688017Z Selecting previously unselected package g++-mingw-w64-i686.
2019-07-16T17:48:21.1721293Z Preparing to unpack .../g++-mingw-w64-i686_5.3.1-8ubuntu3+17_amd64.deb ...
2019-07-16T17:48:21.1866691Z Unpacking g++-mingw-w64-i686 (5.3.1-8ubuntu3+17) ...
2019-07-16T17:48:25.1033489Z Selecting previously unselected package mingw-w64-x86-64-dev.
2019-07-16T17:48:25.1062277Z Preparing to unpack .../mingw-w64-x86-64-dev_4.0.4-2_all.deb ...
2019-07-16T17:48:25.1194895Z Unpacking mingw-w64-x86-64-dev (4.0.4-2) ...
2019-07-16T17:48:27.0689680Z Selecting previously unselected package gcc-mingw-w64-x86-64.
2019-07-16T17:48:27.0723724Z Preparing to unpack .../gcc-mingw-w64-x86-64_5.3.1-8ubuntu3+17_amd64.deb ...
2019-07-16T17:48:27.0859206Z Unpacking gcc-mingw-w64-x86-64 (5.3.1-8ubuntu3+17) ...
2019-07-16T17:48:31.7413447Z Selecting previously unselected package g++-mingw-w64-x86-64.
2019-07-16T17:48:31.7439821Z Preparing to unpack .../g++-mingw-w64-x86-64_5.3.1-8ubuntu3+17_amd64.deb ...
2019-07-16T17:48:31.7580036Z Unpacking g++-mingw-w64-x86-64 (5.3.1-8ubuntu3+17) ...
2019-07-16T17:48:35.9214763Z Selecting previously unselected package g++-mingw-w64.
2019-07-16T17:48:35.9257137Z Preparing to unpack .../g++-mingw-w64_5.3.1-8ubuntu3+17_all.deb ...
2019-07-16T17:48:35.9408296Z Unpacking g++-mingw-w64 (5.3.1-8ubuntu3+17) ...
2019-07-16T17:48:36.0513367Z Selecting previously unselected package gcc-mingw-w64.
2019-07-16T17:48:36.0540804Z Preparing to unpack .../gcc-mingw-w64_5.3.1-8ubuntu3+17_all.deb ...
2019-07-16T17:48:36.0705728Z Unpacking gcc-mingw-w64 (5.3.1-8ubuntu3+17) ...
2019-07-16T17:48:36.1489678Z Selecting previously unselected package mingw-w64.
2019-07-16T17:48:36.1518248Z Preparing to unpack .../mingw-w64_4.0.4-2_all.deb ...
2019-07-16T17:48:36.1647407Z Unpacking mingw-w64 (4.0.4-2) ...
2019-07-16T17:48:36.4018595Z Setting up libgdbm3:amd64 (1.8.3-13.1) ...
2019-07-16T17:48:36.4686840Z Setting up libffi6:amd64 (3.2.1-4) ...
2019-07-16T17:48:36.5056547Z Setting up libglib2.0-0:amd64 (2.48.2-0ubuntu4.3) ...
2019-07-16T17:48:36.5318571Z No schema files found: doing nothing.
---
2019-07-16T17:48:41.7870775Z Setting up zlib1g-dev:amd64 (1:1.2.8.dfsg-2ubuntu4.1) ...
2019-07-16T17:48:41.8272976Z Setting up libssl-dev:amd64 (1.0.2g-1ubuntu4.15) ...
2019-07-16T17:48:41.8676003Z Setting up pkg-config (0.29.1-0ubuntu1) ...
2019-07-16T17:48:41.9520069Z Setting up python2.7 (2.7.12-1ubuntu0~16.04.4) ...
2019-07-16T17:48:42.7751743Z Setting up binutils-mingw-w64-i686 (2.26-3ubuntu1+6.6) ...
2019-07-16T17:48:42.8128511Z Setting up binutils-mingw-w64-x86-64 (2.26-3ubuntu1+6.6) ...
2019-07-16T17:48:42.8507950Z Setting up mingw-w64-common (4.0.4-2) ...
2019-07-16T17:48:42.8880595Z Setting up mingw-w64-i686-dev (4.0.4-2) ...
2019-07-16T17:48:42.9291005Z Setting up gcc-mingw-w64-base (5.3.1-8ubuntu3+17) ...
2019-07-16T17:48:42.9648642Z Setting up gcc-mingw-w64-i686 (5.3.1-8ubuntu3+17) ...
2019-07-16T17:48:42.9917579Z update-alternatives: using /usr/bin/i686-w64-mingw32-gcc-posix to provide /usr/bin/i686-w64-mingw32-gcc (i686-w64-mingw32-gcc) in auto mode
2019-07-16T17:48:42.9920399Z update-alternatives: warning: skip creation of /usr/bin/i686-w64-mingw32-gcc-5 because associated file /usr/bin/i686-w64-mingw32-gcc-5-posix (of link group i686-w64-mingw32-gcc) doesn't exist
2019-07-16T17:48:43.0010838Z update-alternatives: using /usr/bin/i686-w64-mingw32-gcc-win32 to provide /usr/bin/i686-w64-mingw32-gcc (i686-w64-mingw32-gcc) in auto mode
2019-07-16T17:48:43.0014319Z update-alternatives: warning: skip creation of /usr/bin/i686-w64-mingw32-gcc-5 because associated file /usr/bin/i686-w64-mingw32-gcc-5-win32 (of link group i686-w64-mingw32-gcc) doesn't exist
2019-07-16T17:48:43.0254493Z Setting up g++-mingw-w64-i686 (5.3.1-8ubuntu3+17) ...
2019-07-16T17:48:43.0530182Z update-alternatives: using /usr/bin/i686-w64-mingw32-g++-posix to provide /usr/bin/i686-w64-mingw32-g++ (i686-w64-mingw32-g++) in auto mode
2019-07-16T17:48:43.0636544Z update-alternatives: using /usr/bin/i686-w64-mingw32-g++-win32 to provide /usr/bin/i686-w64-mingw32-g++ (i686-w64-mingw32-g++) in auto mode
2019-07-16T17:48:43.0868469Z Setting up mingw-w64-x86-64-dev (4.0.4-2) ...
2019-07-16T17:48:43.1268113Z Setting up gcc-mingw-w64-x86-64 (5.3.1-8ubuntu3+17) ...
2019-07-16T17:48:43.1543693Z update-alternatives: using /usr/bin/x86_64-w64-mingw32-gcc-posix to provide /usr/bin/x86_64-w64-mingw32-gcc (x86_64-w64-mingw32-gcc) in auto mode
2019-07-16T17:48:43.1548653Z update-alternatives: warning: skip creation of /usr/bin/x86_64-w64-mingw32-gcc-5 because associated file /usr/bin/x86_64-w64-mingw32-gcc-5-posix (of link group x86_64-w64-mingw32-gcc) doesn't exist
2019-07-16T17:48:43.1634816Z update-alternatives: using /usr/bin/x86_64-w64-mingw32-gcc-win32 to provide /usr/bin/x86_64-w64-mingw32-gcc (x86_64-w64-mingw32-gcc) in auto mode
2019-07-16T17:48:43.1635400Z update-alternatives: warning: skip creation of /usr/bin/x86_64-w64-mingw32-gcc-5 because associated file /usr/bin/x86_64-w64-mingw32-gcc-5-win32 (of link group x86_64-w64-mingw32-gcc) doesn't exist
2019-07-16T17:48:43.1879890Z Setting up g++-mingw-w64-x86-64 (5.3.1-8ubuntu3+17) ...
2019-07-16T17:48:43.2156443Z update-alternatives: using /usr/bin/x86_64-w64-mingw32-g++-posix to provide /usr/bin/x86_64-w64-mingw32-g++ (x86_64-w64-mingw32-g++) in auto mode
2019-07-16T17:48:43.2257228Z update-alternatives: using /usr/bin/x86_64-w64-mingw32-g++-win32 to provide /usr/bin/x86_64-w64-mingw32-g++ (x86_64-w64-mingw32-g++) in auto mode
2019-07-16T17:48:43.2520023Z Setting up g++-mingw-w64 (5.3.1-8ubuntu3+17) ...
2019-07-16T17:48:43.2940913Z Setting up gcc-mingw-w64 (5.3.1-8ubuntu3+17) ...
2019-07-16T17:48:43.3348347Z Setting up mingw-w64 (4.0.4-2) ...
2019-07-16T17:48:43.4189728Z Processing triggers for ca-certificates (20170717~16.04.2) ...
2019-07-16T17:48:43.4349872Z Updating certificates in /etc/ssl/certs...
2019-07-16T17:48:45.0008774Z 148 added, 0 removed; done.
2019-07-16T17:48:45.0009601Z Running hooks in /etc/ca-certificates/update.d...
---
2019-07-16T17:49:25.6453785Z  ---> 4d29dc89741d
2019-07-16T17:49:25.6488532Z Successfully built 4d29dc89741d
2019-07-16T17:49:25.8017910Z Successfully tagged rust-ci:latest
2019-07-16T17:49:25.8940013Z Built container sha256:4d29dc89741d079293f8114a61b093e3d50ce28e6b43bf979b9131cd68bab9bd
2019-07-16T17:49:25.8954789Z Uploading finished image to https://.s3.amazonaws.com/docker/a4940e6914a5e1f6360ebc241d0d850aff083be5c43d268fd716ce48f63cb24e84238becb662f27f8c5d7740413ca17da24bb9cdc003ef32d7b03d2c9052b94d
2019-07-16T17:50:49.3656268Z upload failed: - to s3:///docker/a4940e6914a5e1f6360ebc241d0d850aff083be5c43d268fd716ce48f63cb24e84238becb662f27f8c5d7740413ca17da24bb9cdc003ef32d7b03d2c9052b94d Parameter validation failed:
2019-07-16T17:50:49.3656739Z Invalid bucket name "": Bucket name must match the regex "^[a-zA-Z0-9.\-_]{1,255}$"
2019-07-16T17:50:50.3572300Z [CI_JOB_NAME=mingw-check]
2019-07-16T17:50:50.3624925Z Starting sccache server...
2019-07-16T17:50:50.4246025Z configure: processing command line
2019-07-16T17:50:50.4246189Z configure: 
---
2019-07-16T17:56:37.4776733Z     Checking rustc_ast_borrowck v0.0.0 (/checkout/src/librustc_ast_borrowck)
2019-07-16T17:56:38.8272574Z     Checking rustc_lint v0.0.0 (/checkout/src/librustc_lint)
2019-07-16T17:56:40.5598837Z     Checking rustc_traits v0.0.0 (/checkout/src/librustc_traits)
2019-07-16T17:56:41.8981450Z     Checking rustc_codegen_utils v0.0.0 (/checkout/src/librustc_codegen_utils)
2019-07-16T17:56:42.4108017Z error[E0621]: explicit lifetime required in the type of `place_span`
2019-07-16T17:56:42.4118811Z    --> src/librustc_mir/borrow_check/mod.rs:986:13
2019-07-16T17:56:42.4125445Z     |
2019-07-16T17:56:42.4131680Z 931 |           place_span: (&Place<'tcx>, Span),
2019-07-16T17:56:42.4183155Z     |                       -------------------- help: add explicit lifetime `'cx` to the type of `place_span`: `(&'cx rustc::mir::Place<'tcx>, syntax_pos::span_encoding::Span)`
2019-07-16T17:56:42.4183777Z 986 | /             self.access_place_error_reported
2019-07-16T17:56:42.4183777Z 986 | /             self.access_place_error_reported
2019-07-16T17:56:42.4185159Z 987 | |                 .insert((place_span.0.as_place_ref(), place_span.1));
2019-07-16T17:56:42.4185554Z     | |____________________________________________________________________^ lifetime `'cx` required
2019-07-16T17:56:42.4185602Z 
2019-07-16T17:56:42.4464544Z error[E0521]: borrowed data escapes outside of function
2019-07-16T17:56:42.4468458Z     --> src/librustc_mir/borrow_check/mod.rs:1615:15
2019-07-16T17:56:42.4474994Z 1571 |         &mut self,
2019-07-16T17:56:42.4478794Z      |         ---------
2019-07-16T17:56:42.4484531Z      |         |
2019-07-16T17:56:42.4484531Z      |         |
2019-07-16T17:56:42.4485093Z      |         `self` is declared here, outside of the function body
2019-07-16T17:56:42.4485488Z      |         `self` is a reference that is only valid in the function body
2019-07-16T17:56:42.4485705Z ...
2019-07-16T17:56:42.4485992Z 1615 |         match self.move_path_closest_to(place_span.0) {
2019-07-16T17:56:42.4486972Z      |               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ `self` escapes the function body here
2019-07-16T17:56:42.4487025Z 
2019-07-16T17:56:42.4487308Z error[E0499]: cannot borrow `*self` as mutable more than once at a time
2019-07-16T17:56:42.4487604Z     --> src/librustc_mir/borrow_check/mod.rs:1618:21
2019-07-16T17:56:42.4487849Z      |
2019-07-16T17:56:42.4488161Z 1549 | impl<'cx, 'tcx> MirBorrowckCtxt<'cx, 'tcx> {
2019-07-16T17:56:42.4488479Z      |      --- lifetime `'cx` defined here
2019-07-16T17:56:42.4488694Z ...
2019-07-16T17:56:42.4489017Z 1615 |         match self.move_path_closest_to(place_span.0) {
2019-07-16T17:56:42.4489585Z      |               |
2019-07-16T17:56:42.4489585Z      |               |
2019-07-16T17:56:42.4489895Z      |               first mutable borrow occurs here
2019-07-16T17:56:42.4490365Z      |               argument requires that `*self` is borrowed for `'cx`
2019-07-16T17:56:42.4490572Z ...
2019-07-16T17:56:42.4490882Z 1618 |                     self.report_use_of_moved_or_uninitialized(
2019-07-16T17:56:42.4491201Z      |                     ^^^^ second mutable borrow occurs here
2019-07-16T17:56:42.4491251Z 
2019-07-16T17:56:42.4507485Z error[E0621]: explicit lifetime required in the type of `place_span`
2019-07-16T17:56:42.4507879Z     --> src/librustc_mir/borrow_check/mod.rs:1676:17
2019-07-16T17:56:42.4508135Z      |
2019-07-16T17:56:42.4508425Z 1642 |           place_span: (&Place<'tcx>, Span),
2019-07-16T17:56:42.4508871Z      |                       -------------------- help: add explicit lifetime `'cx` to the type of `place_span`: `(&'cx rustc::mir::Place<'tcx>, syntax_pos::span_encoding::Span)`
2019-07-16T17:56:42.4509118Z ...
2019-07-16T17:56:42.4511398Z 1676 | /                 self.report_use_of_moved_or_uninitialized(
2019-07-16T17:56:42.4512111Z 1677 | |                     location,
2019-07-16T17:56:42.4512883Z 1678 | |                     desired_action,
2019-07-16T17:56:42.4513299Z 1679 | |                     (place_span.0.as_place_ref(), place_span.0, place_span.1),
2019-07-16T17:56:42.4513790Z 1680 | |                     child_mpi,
2019-07-16T17:56:42.4514134Z 1681 | |                 );
2019-07-16T17:56:42.4514426Z      | |_________________^ lifetime `'cx` required
2019-07-16T17:56:42.4514547Z 
2019-07-16T17:56:42.4529004Z error: lifetime may not live long enough
2019-07-16T17:56:42.4529359Z     --> src/librustc_mir/borrow_check/mod.rs:1705:24
2019-07-16T17:56:42.4653672Z 1698 |         &mut self,
2019-07-16T17:56:42.4654073Z      |         - let's call the lifetime of this reference `'2`
2019-07-16T17:56:42.4654073Z      |         - let's call the lifetime of this reference `'2`
2019-07-16T17:56:42.4654449Z 1699 |         place: &Place<'tcx>,
2019-07-16T17:56:42.4655074Z ...
2019-07-16T17:56:42.4655074Z ...
2019-07-16T17:56:42.4655386Z 1705 |                 return Ok((prefix, mpi));
2019-07-16T17:56:42.4655958Z      |                        ^^^^^^^^^^^^^^^^^ function was supposed to return data with lifetime `'2` but it is returning data with lifetime `'1`
2019-07-16T17:56:42.4656039Z 
2019-07-16T17:56:42.4656347Z error[E0621]: explicit lifetime required in the type of `base`
2019-07-16T17:56:42.4657721Z     --> src/librustc_mir/borrow_check/mod.rs:1861:27
2019-07-16T17:56:42.4658200Z      |
2019-07-16T17:56:42.4658658Z 1821 |             base: &Place<'tcx>,
2019-07-16T17:56:42.4659244Z      |                   ------------ help: add explicit lifetime `'cx` to the type of `base`: `&'cx rustc::mir::Place<'tcx>`
2019-07-16T17:56:42.4659645Z ...
2019-07-16T17:56:42.4660162Z 1861 |             for prefix in this.prefixes(base.as_place_ref(), PrefixSet::Shallow) {
2019-07-16T17:56:42.4661328Z      |                           |
2019-07-16T17:56:42.4661328Z      |                           |
2019-07-16T17:56:42.4661782Z      |                           lifetime `'cx` required
2019-07-16T17:56:42.4662272Z      |                           in this expansion of `desugaring of `for loop``
2019-07-16T17:56:42.4662886Z 
2019-07-16T17:56:42.5797252Z     Checking rustc_resolve v0.0.0 (/checkout/src/librustc_resolve)
2019-07-16T17:56:42.5797252Z     Checking rustc_resolve v0.0.0 (/checkout/src/librustc_resolve)
2019-07-16T17:56:42.6299461Z error[E0621]: explicit lifetime required in parameter type
2019-07-16T17:56:42.6317270Z    |
2019-07-16T17:56:42.6317270Z    |
2019-07-16T17:56:42.6324572Z 51 |           (moved_place, used_place, span): (PlaceRef<'cx, 'tcx>, &Place<'tcx>, Span),
2019-07-16T17:56:42.6381137Z    |                                            ----------------------------------------- help: add explicit lifetime `'cx` to type: `(rustc::mir::PlaceRef<'cx, 'tcx>, &'cx rustc::mir::Place<'tcx>, syntax_pos::span_encoding::Span)`
2019-07-16T17:56:42.6381720Z ...
2019-07-16T17:56:42.6382018Z 75 |               let root_place = self
2019-07-16T17:56:42.6382281Z    |  ______________________________^
2019-07-16T17:56:42.6382602Z 76 | |                 .prefixes(used_place.as_place_ref(), PrefixSet::All)
2019-07-16T17:56:42.6382977Z    | |____________________________________________________________________^ lifetime `'cx` required
2019-07-16T17:56:42.6383022Z 
2019-07-16T17:56:42.7117495Z error[E0621]: explicit lifetime required in the type of `borrow`
2019-07-16T17:56:42.7129126Z     |
2019-07-16T17:56:42.7129126Z     |
2019-07-16T17:56:42.7135004Z 683 |         borrow: &BorrowData<'tcx>,
2019-07-16T17:56:42.7143397Z     |                 ----------------- help: add explicit lifetime `'cx` to the type of `borrow`: `&'cx borrow_check::borrow_set::BorrowData<'tcx>`
2019-07-16T17:56:42.7147228Z ...
2019-07-16T17:56:42.7179927Z 695 |         let root_place = self.prefixes(borrow.borrowed_place.as_place_ref(), PrefixSet::All)
2019-07-16T17:56:42.7180603Z     |                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ lifetime `'cx` required
2019-07-16T17:56:45.2386716Z     Checking rustc_plugin v0.0.0 (/checkout/src/librustc_plugin)
2019-07-16T17:56:45.5232872Z     Checking rustc_privacy v0.0.0 (/checkout/src/librustc_privacy)
2019-07-16T17:56:46.1163594Z     Checking rustc_codegen_ssa v0.0.0 (/checkout/src/librustc_codegen_ssa)
2019-07-16T17:56:49.0701417Z error: aborting due to 8 previous errors
2019-07-16T17:56:49.0701417Z error: aborting due to 8 previous errors
2019-07-16T17:56:49.0705262Z 
2019-07-16T17:56:49.0711545Z Some errors have detailed explanations: E0499, E0621.
2019-07-16T17:56:49.0716513Z For more information about an error, try `rustc --explain E0499`.
2019-07-16T17:56:49.1858826Z error: Could not compile `rustc_mir`.
2019-07-16T17:56:49.1859198Z warning: build failed, waiting for other jobs to finish...
2019-07-16T17:56:50.8245029Z error: build failed
2019-07-16T17:56:50.8264565Z command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "check" "--target" "x86_64-unknown-linux-gnu" "-j" "2" "--release" "--color" "always" "--features" "" "--manifest-path" "/checkout/src/rustc/Cargo.toml" "--message-format" "json"
2019-07-16T17:56:50.8279087Z failed to run: /checkout/obj/build/bootstrap/debug/bootstrap check
2019-07-16T17:56:50.8279495Z Build completed unsuccessfully in 0:06:00
2019-07-16T17:56:50.8279495Z Build completed unsuccessfully in 0:06:00
2019-07-16T17:56:52.0806231Z ##[error]Bash exited with code '1'.
2019-07-16T17:56:52.0839655Z ##[section]Starting: Checkout
2019-07-16T17:56:52.0841590Z ==============================================================================
2019-07-16T17:56:52.0841654Z Task         : Get sources
2019-07-16T17:56:52.0841697Z Description  : Get sources from a repository. Supports Git, TfsVC, and SVN repositories.

</details><p></p>

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

spastorino

comment created time in 15 minutes

Pull request review commentrust-lang/rust

[WIP] Elide allocation of uninit static

 pub struct Allocation<Tag=(),Extra=()> {     pub extra: Extra, } +#[derive(Clone, Debug, Eq, PartialEq, PartialOrd, Ord, Hash, RustcEncodable, RustcDecodable)]+pub struct AllocationBytes {+    /// The actual bytes of the allocation.+    /// Note that the bytes of a pointer represent the offset of the pointer+    pub bytes: Vec<u8>,+    /// Denotes undefined memory. Reading from undefined memory is forbidden in miri+    pub undef_mask: UndefMask,+}++pub enum BytesOrElidedUndef<'a> {+    /// Some bytes that may be undef but were not elided.+    MaybeBytes(&'a [u8]),+    /// An undef that has never been written to and was not yet allocated.+    ElidedUndef,+}

If you call get_bytes though, they will be initialized. And if you call get_bytes_with_undef_and_ptr or whatever we called it, you better read the docs.

HeroicKatora

comment created time in 17 minutes

Pull request review commentrust-lang/cargo

Fix some issues with absolute paths in dep-info files.

 pub fn parse_dep_info(             }         })         .collect::<Result<Vec<_>, _>>()?;-    if paths.is_empty() {-        Ok(None)-    } else {-        Ok(Some(paths))-    }+    Ok(Some(paths))

Yea, I couldn't figure out why this check was added in 4788. The main gist is that when building a registry dependency with current rustc, the list would end up empty (everything gets filtered out), and cargo would treat it as "dirty" when it should be fine. By instead returning an empty list, it treats it correctly.

ehuss

comment created time in 18 minutes

issue commentrust-lang/unsafe-code-guidelines

Layout of repr(C) unions has padding

My reading of https://github.com/rust-lang/rust/issues/60405#issuecomment-507838717 is that it is impossible to achieve "raw bit copy" for extern "C" with a repr(C) union, but I might be misinterpreting that.

gnzlbg

comment created time in 18 minutes

Pull request review commentrust-lang/unsafe-code-guidelines

Resolve layout of single variant enums

 enum Enum1<T> { } ``` -## Unresolved questions- ### Layout of single variant enums -[Issue #79.](https://github.com/rust-rfcs/unsafe-code-guidelines/issues/79)--Enums that contain a **single variant** and which do not have an-explicit `#[repr]` annotation are an important special case. Since-there is only a single variant, the enum must be instantiated with-that variant, which means that the enum is in fact equivalent to a-struct. The question then is to what extent we should **guarantee**-that the two share an equivalent layout, and also how to define the-interaction with uninhabited types.+**Single variant data-carrying*** enums without a `repr()` annotation have the+same layout as the variant field. **Single variant fieldless** enums have the+same layout as a unit struct. -As presently implemented, the compiler will use the same layout for-structs and for single variant enums (as long as they do not have a-`#[repr]` annotation that overrides that choice). So, for example, the-struct `SomeStruct` and the enum `SomeEnum` would have an equivalent-layout ([playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=3697ac684c3d021892694956df957653)):+Here:  ```rust-struct SomeStruct;-enum SomeEnum {-  SomeVariant,-}-+# use std::mem::{size_of, align_of};+struct UnitStruct;+enum SingleVariantFieldless { FieldlessVariant } # fn main() {-# use std::mem;-let x = SomeStruct;-let y = SomeEnum::SomeVariant;-assert_eq!(-    mem::size_of_val(&x), -    mem::size_of_val(&y),-    "types have different sizes",-);-println!("types both have size {}", std::mem::size_of_val(&x));+assert_eq!(size_of::<SingleVariantFieldless>(), size_of::<UnitStruct>());+assert_eq!(align_of::<SingleVariantFieldless>(), align_of::<UnitStruct>());+// assert_eq!(call_abi_of::<SingleVariantFieldless>(), call_abi_of::<UnitStruct>());+// assert_eq!(niches_of::<SingleVariantFieldless>(), niches_of::<UnitStruct>()); # } ``` -Similarly, the struct `SomeStruct` and the enum `SomeVariant` in this-example would also be equivalent in their layout-([playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=924724764419f846c788a8763da45992)):+the single-variant fieldless enum `SingleVariantFieldless` has the same layout+as `UnitStruct`.++Here:   ```rust+# use std::mem::{size_of, align_of}; struct SomeStruct { x: u32 }-enum SomeEnum {-  SomeVariant { x: u32 },+enum SingleVariantDataCarrying {+  DataCarryingVariant(SomeStruct), }- # fn main() {-# use std::mem;-let x = SomeStruct { x: 22 };-let y = SomeEnum::SomeVariant { x: 22 };-assert_eq!(-    mem::size_of_val(&x), -    mem::size_of_val(&y),-    "types have different sizes",-);-println!("types both have size {}", mem::size_of_val(&x));-}+# assert_eq!(size_of::<SingleVariantDataCarrying>(), size_of::<SomeStruct>());+# assert_eq!(align_of::<SingleVariantDataCarrying>(), align_of::<SomeStruct>());+# } ``` -In fact, the compiler will use this optimized layout even for enums-that define multiple variants, as long as all but one of the variants-is uninhabited-([playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=3cc1484c5b91097f3dc2015b7c207a0e)):+the single-variant data-carrying enum `SingleVariantDataCarrying` has the same+layout as `SomeStruct`.++### Layout of multi-variant enums with one inhabited variant++The layout of **multi-variant** enums with **one inhabited variant** is the same

Good question! I don't know. &! might be such a type, depending on how the validity invariant discussions turn out.

Declaring that these two notions (the first two in my list) are equal would put a restriction on the validity invariant discussion: we would have to make sure that satisfiability is trivially computable and can be put into the rustc layout code. I think this would be a nice property to have, but I wouldn't want to assert now that we will end up there.

gnzlbg

comment created time in 19 minutes

push eventrust-lang/crates.io-index

bors

commit sha db2ae7b3fcbd40593b51d56bf762ca97d4c1863c

Updating crate `oorandom#9.3.0`

view details

push time in 20 minutes

push eventrust-lang/crates.io-index

bors

commit sha 5851bdb5e180708ad1854038ccc5f7ceeb9d0a2d

Updating crate `cl-traits#0.3.0`

view details

push time in 20 minutes

Pull request review commentrust-lang/rust

[WIP] Elide allocation of uninit static

 pub struct Allocation<Tag=(),Extra=()> {     pub extra: Extra, } +#[derive(Clone, Debug, Eq, PartialEq, PartialOrd, Ord, Hash, RustcEncodable, RustcDecodable)]+pub struct AllocationBytes {+    /// The actual bytes of the allocation.+    /// Note that the bytes of a pointer represent the offset of the pointer+    pub bytes: Vec<u8>,+    /// Denotes undefined memory. Reading from undefined memory is forbidden in miri+    pub undef_mask: UndefMask,+}++pub enum BytesOrElidedUndef<'a> {+    /// Some bytes that may be undef but were not elided.+    MaybeBytes(&'a [u8]),+    /// An undef that has never been written to and was not yet allocated.+    ElidedUndef,+}

This is a proper enum because the Some variant may be easily misunderstood as meaning initialized bytes when in reality the range of MaybeBytes may still contain bytes in a logically uninitialized state.

HeroicKatora

comment created time in 20 minutes

Pull request review commentrust-lang/cargo

Fix some issues with absolute paths in dep-info files.

 where      for path in paths {         let path = path.as_ref();-        let path_mtime = match paths::mtime(path) {-            Ok(mtime) => mtime,-            Err(..) => return Some(StaleFile::Missing(path.to_path_buf())),+        let path_mtime = match mtime_cache.entry(path.to_path_buf()) {

Yes, it is all done at the beginning.

It can also deduplicate other paths as well. For example, when doing cargo build --tests then main.rs will show up twice (once as a dep of the bin executable, and once as the bin unittest). There are a variety of other situations (using the same modules from different targets, include shenanigans, etc.). I'm fairly confident they should all be fine.

ehuss

comment created time in 21 minutes

Pull request review commentrust-lang/rust

[WIP] Elide allocation of uninit static

 pub struct Allocation<Tag=(),Extra=()> {     pub extra: Extra, } +#[derive(Clone, Debug, Eq, PartialEq, PartialOrd, Ord, Hash, RustcEncodable, RustcDecodable)]+pub struct AllocationBytes {+    /// The actual bytes of the allocation.+    /// Note that the bytes of a pointer represent the offset of the pointer+    pub bytes: Vec<u8>,+    /// Denotes undefined memory. Reading from undefined memory is forbidden in miri

I did: "Denotes which part of this allocation is initialized". I wouldn't talk about what exact consequences that has as those rules are changing.

If you really want you can link to https://www.ralfj.de/blog/2019/07/14/uninit.html for an explanation why explicit tracking is needed. ;)

HeroicKatora

comment created time in 22 minutes

pull request commentrust-lang/rust

Deprecate using rustc_plugin without the rustc_driver dylib.

r? @Zoxc

SimonSapin

comment created time in 24 minutes

Pull request review commentrust-lang/rust

[WIP] Elide allocation of uninit static

 impl<'tcx, Tag: Copy, Extra: AllocationExtra<Tag>> Allocation<Tag, Extra> {         size: Size,     ) -> InterpResult<'tcx, &[u8]>     {-        self.get_bytes_internal(cx, ptr, size, true)+        self.get_bytes_internal(cx, ptr, size, true).map(|bytes_or_undef| match bytes_or_undef {+            BytesOrElidedUndef::MaybeBytes(bytes) => bytes,+            BytesOrElidedUndef::ElidedUndef => {+                // Any other size would have triggered the definedness check.+                debug_assert_eq!(size, Size::ZERO);

Oh lol I just noticed @oli-obk told you to use debug_assert.

@oli-obk I think we shouldn't elide this for release builds, this feels like the kind of thing that mis-use of the allocation API anywhere in the Miri engine can trigger.

HeroicKatora

comment created time in 24 minutes

Pull request review commentrust-lang/rust

[WIP] Elide allocation of uninit static

 impl<'tcx, Tag: Copy, Extra: AllocationExtra<Tag>> Allocation<Tag, Extra> {         size: Size,     ) -> InterpResult<'tcx, &[u8]>     {-        self.get_bytes_internal(cx, ptr, size, true)+        self.get_bytes_internal(cx, ptr, size, true).map(|bytes_or_undef| match bytes_or_undef {+            BytesOrElidedUndef::MaybeBytes(bytes) => bytes,+            BytesOrElidedUndef::ElidedUndef => {+                // Any other size would have triggered the definedness check.+                debug_assert_eq!(size, Size::ZERO);

It was @oli-obk who proposed a debug_assert_eq! here.

HeroicKatora

comment created time in 24 minutes

Pull request review commentrust-lang/rust

[WIP] Elide allocation of uninit static

 use std::borrow::Cow;  #[derive(Clone, Debug, Eq, PartialEq, PartialOrd, Ord, Hash, RustcEncodable, RustcDecodable)] pub struct Allocation<Tag=(),Extra=()> {-    /// The actual bytes of the allocation.-    /// Note that the bytes of a pointer represent the offset of the pointer-    pub bytes: Vec<u8>,+    /// The byte allocation and definedness.+    /// Bytes of fully undefined allocations are allocated lazily on potentially mutable changes.+    pub alloc: Option<AllocationBytes>,

alloc is usually used as name for something of type Allocation. Here and below, you are breaking with that pattern. Maybe call this alloc_bytes, or alloc_content? In the latter case the type should also change to AllocationContent.

HeroicKatora

comment created time in 25 minutes

pull request commentrust-lang/rust

Deprecate using rustc_plugin without the rustc_driver dylib.

r? @petrochenkov

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

SimonSapin

comment created time in 25 minutes

PR opened rust-lang/rust

Deprecate using rustc_plugin without the rustc_driver dylib.

CC https://github.com/rust-lang/rust/pull/59800, https://github.com/rust-lang/rust/commit/7198687bb2df13a3298ef1e8f594753073d6b9e8

Fix https://github.com/rust-lang/rust/issues/62717

+52 -34

0 comment

22 changed files

pr created time in 25 minutes

Pull request review commentrust-lang/rust

[WIP] Elide allocation of uninit static

 impl<'tcx, Tag: Copy, Extra> Allocation<Tag, Extra> {  /// Undefined bytes impl<'tcx, Tag, Extra> Allocation<Tag, Extra> {+    #[inline]+    fn check_defined(&self, ptr: Pointer<Tag>, size: Size) -> InterpResult<'tcx> {+        match &self.alloc {+            Some(alloc) => alloc.check_defined(ptr.offset, size),+            None if size == Size::ZERO && ptr.offset <= self.size => Ok(()),+            None => err!(ReadUndefBytes(ptr.offset)),+        }+    }++    /// Directly query the UndefMask for a range.+    /// Does not go through any interpreter hooks so only use for debugging.+    pub fn check_raw_range_defined(&self, start: Size, end: Size) -> Result<(), Size> {+        match &self.alloc {+            Some(alloc) => alloc.undef_mask.is_range_defined(start, end),+            None if start == end && end <= self.size => Ok(()),+            None => Err(start),+        }+    }++    pub fn mark_definedness(+        &mut self,+        ptr: Pointer<Tag>,+        size: Size,+        new_state: bool,+    ) {+        let alloc = self.force_allocation();+        alloc.mark_definedness(ptr.offset, size, new_state)+    }++    /// If an all undef allocation was elided allocate now. Does nothing otherwise.+    pub fn force_allocation(&mut self) -> &mut AllocationBytes {

We also have a force_allocation method in the Miri engine in librsutc_mir and it is very different. Can we avoid using the same name for two very different operations?

HeroicKatora

comment created time in 26 minutes

issue commentrust-lang/rust

Spurious "note: downstream crates may implement trait `Foo` for type `&_`"

Any updates fam?

glandium

comment created time in 27 minutes

Pull request review commentrust-lang/rust

[WIP] Elide allocation of uninit static

 impl<'tcx, Tag: Copy, Extra: AllocationExtra<Tag>> Allocation<Tag, Extra> {         size: Size,     ) -> InterpResult<'tcx, &[u8]>     {-        self.get_bytes_internal(cx, ptr, size, true)+        self.get_bytes_internal(cx, ptr, size, true).map(|bytes_or_undef| match bytes_or_undef {+            BytesOrElidedUndef::MaybeBytes(bytes) => bytes,+            BytesOrElidedUndef::ElidedUndef => {+                // Any other size would have triggered the definedness check.+                debug_assert_eq!(size, Size::ZERO);

Please make this assert_eq! unless we have benchmarks showing that this is expensive.

HeroicKatora

comment created time in 28 minutes

Pull request review commentrust-lang/rust

[WIP] Elide allocation of uninit static

 pub struct Allocation<Tag=(),Extra=()> {     pub extra: Extra, } +#[derive(Clone, Debug, Eq, PartialEq, PartialOrd, Ord, Hash, RustcEncodable, RustcDecodable)]+pub struct AllocationBytes {+    /// The actual bytes of the allocation.+    /// Note that the bytes of a pointer represent the offset of the pointer+    pub bytes: Vec<u8>,+    /// Denotes undefined memory. Reading from undefined memory is forbidden in miri+    pub undef_mask: UndefMask,+}++pub enum BytesOrElidedUndef<'a> {+    /// Some bytes that may be undef but were not elided.+    MaybeBytes(&'a [u8]),+    /// An undef that has never been written to and was not yet allocated.+    ElidedUndef,+}

I am not convinced that this is better than using Option. But if we stick with it, I don't think the "not yet allocated" part should matter, and the 2nd variant should be just Undef. There is no reason to leak the details of when we can easily know that the entire range is Undef.

HeroicKatora

comment created time in 28 minutes

push eventrust-lang/crates.io-index

bors

commit sha 3ca4efc3c57f694a4a4c8e44d876b156a0af360a

Updating crate `contrie#0.1.4`

view details

push time in 29 minutes

Pull request review commentrust-lang/rust

[WIP] Elide allocation of uninit static

 pub struct Allocation<Tag=(),Extra=()> {     pub extra: Extra, } +#[derive(Clone, Debug, Eq, PartialEq, PartialOrd, Ord, Hash, RustcEncodable, RustcDecodable)]+pub struct AllocationBytes {+    /// The actual bytes of the allocation.+    /// Note that the bytes of a pointer represent the offset of the pointer+    pub bytes: Vec<u8>,+    /// Denotes undefined memory. Reading from undefined memory is forbidden in miri

This was meant as 'interpreting undefined memory as a value of some type' is forbidden, i.e. not even integral values such as u32 are allowed to be uninitialized. Can you propose a clearer alternative documentation?

HeroicKatora

comment created time in 29 minutes

push eventrust-lang/crates.io-index

bors

commit sha 97cbe5b11e04e226244c287fb65f1baad8dd7467

Updating crate `timekeeper#0.3.1`

view details

push time in 29 minutes

Pull request review commentrust-lang/rust

[WIP] Elide allocation of uninit static

 impl<Tag> Allocation<Tag> {     }      pub fn undef(size: Size, align: Align) -> Self {+        // Ensure initialization later gives the correct length.         assert_eq!(size.bytes() as usize as u64, size.bytes());         Allocation {-            bytes: vec![0; size.bytes() as usize],+            alloc: None,             relocations: Relocations::new(),-            undef_mask: UndefMask::new(size, false),+            size,             align,             mutability: Mutability::Mutable,             extra: (),         }     } } +/// Raw accessors. Provide compatibility through lazy allocation of undef.+impl<Tag, Extra> Allocation<Tag, Extra> {+    pub fn len(&self) -> usize {+        self.alloc.as_ref()+            .map(|alloc| {+                debug_assert_eq!(alloc.bytes.len() as u64, self.size.bytes());+                alloc.bytes.len()+            })+            .unwrap_or(self.size.bytes() as usize)+    }++    /// Access without going through the logical part of the allocation.+    ///+    /// Interpreter computation should not depend on the content of these bytes and caller has the+    /// ensure the range is valid.+    pub fn get_raw_bytes(&self, range: Range<usize>) -> BytesOrElidedUndef<'_> {

What is "the logical part of the allocation"? Inf act I don't understand any part of this doc comment.

HeroicKatora

comment created time in 29 minutes

Pull request review commentrust-lang/unsafe-code-guidelines

Resolve layout of single variant enums

 enum Enum1<T> { } ``` -## Unresolved questions- ### Layout of single variant enums -[Issue #79.](https://github.com/rust-rfcs/unsafe-code-guidelines/issues/79)--Enums that contain a **single variant** and which do not have an-explicit `#[repr]` annotation are an important special case. Since-there is only a single variant, the enum must be instantiated with-that variant, which means that the enum is in fact equivalent to a-struct. The question then is to what extent we should **guarantee**-that the two share an equivalent layout, and also how to define the-interaction with uninhabited types.+**Single variant data-carrying*** enums without a `repr()` annotation have the+same layout as the variant field. **Single variant fieldless** enums have the+same layout as a unit struct. -As presently implemented, the compiler will use the same layout for-structs and for single variant enums (as long as they do not have a-`#[repr]` annotation that overrides that choice). So, for example, the-struct `SomeStruct` and the enum `SomeEnum` would have an equivalent-layout ([playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=3697ac684c3d021892694956df957653)):+Here:  ```rust-struct SomeStruct;-enum SomeEnum {-  SomeVariant,-}-+# use std::mem::{size_of, align_of};+struct UnitStruct;+enum SingleVariantFieldless { FieldlessVariant } # fn main() {-# use std::mem;-let x = SomeStruct;-let y = SomeEnum::SomeVariant;-assert_eq!(-    mem::size_of_val(&x), -    mem::size_of_val(&y),-    "types have different sizes",-);-println!("types both have size {}", std::mem::size_of_val(&x));+assert_eq!(size_of::<SingleVariantFieldless>(), size_of::<UnitStruct>());+assert_eq!(align_of::<SingleVariantFieldless>(), align_of::<UnitStruct>());+// assert_eq!(call_abi_of::<SingleVariantFieldless>(), call_abi_of::<UnitStruct>());+// assert_eq!(niches_of::<SingleVariantFieldless>(), niches_of::<UnitStruct>()); # } ``` -Similarly, the struct `SomeStruct` and the enum `SomeVariant` in this-example would also be equivalent in their layout-([playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=924724764419f846c788a8763da45992)):+the single-variant fieldless enum `SingleVariantFieldless` has the same layout+as `UnitStruct`.++Here:   ```rust+# use std::mem::{size_of, align_of}; struct SomeStruct { x: u32 }-enum SomeEnum {-  SomeVariant { x: u32 },+enum SingleVariantDataCarrying {+  DataCarryingVariant(SomeStruct), }- # fn main() {-# use std::mem;-let x = SomeStruct { x: 22 };-let y = SomeEnum::SomeVariant { x: 22 };-assert_eq!(-    mem::size_of_val(&x), -    mem::size_of_val(&y),-    "types have different sizes",-);-println!("types both have size {}", mem::size_of_val(&x));-}+# assert_eq!(size_of::<SingleVariantDataCarrying>(), size_of::<SomeStruct>());+# assert_eq!(align_of::<SingleVariantDataCarrying>(), align_of::<SomeStruct>());+# } ``` -In fact, the compiler will use this optimized layout even for enums-that define multiple variants, as long as all but one of the variants-is uninhabited-([playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=3cc1484c5b91097f3dc2015b7c207a0e)):+the single-variant data-carrying enum `SingleVariantDataCarrying` has the same+layout as `SomeStruct`.++### Layout of multi-variant enums with one inhabited variant++The layout of **multi-variant** enums with **one inhabited variant** is the same

Are there types for which "The type's validity invariant is satisfiable" and the call ABI is Uninhabited ?

gnzlbg

comment created time in 30 minutes

Pull request review commentrust-lang/rust

[WIP] Elide allocation of uninit static

 use std::borrow::Cow;  #[derive(Clone, Debug, Eq, PartialEq, PartialOrd, Ord, Hash, RustcEncodable, RustcDecodable)] pub struct Allocation<Tag=(),Extra=()> {-    /// The actual bytes of the allocation.-    /// Note that the bytes of a pointer represent the offset of the pointer-    pub bytes: Vec<u8>,+    /// The byte allocation and definedness.+    /// Bytes of fully undefined allocations are allocated lazily on potentially mutable changes.+    pub alloc: Option<AllocationBytes>,     /// Maps from byte addresses to extra data for each pointer.     /// Only the first byte of a pointer is inserted into the map; i.e.,     /// every entry in this map applies to `pointer_size` consecutive bytes starting     /// at the given offset.     pub relocations: Relocations<Tag>,

Good to have this confirmed, I was about to ask as parts in 'codegen' don't make much sense in that state.

HeroicKatora

comment created time in 31 minutes

Pull request review commentrust-lang/unsafe-code-guidelines

Guarantee the layout of structs with a single non-zero-sized field

 compiler will not reorder it, to allow for the possibility of unsizing. E.g., `struct Foo { x: u16, y: u32 }` and `struct Foo<T> { x: u16, y: T }` where `T = u32` are not guaranteed to be identical. +#### Default layout of structs with a single non-zero-sized field++The default layout of structs with a single non-zero-sized field is the same as+the layout of that field if the alignment requirement of all other fields is 1.

The obvious alternative is 1-ZST. "One-aligned zero-sized type" works better than "zero-sized type, 1-aligned".

I like 1-ZST.

gnzlbg

comment created time in 31 minutes

Pull request review commentrust-lang/rust

[WIP] Elide allocation of uninit static

 pub struct Allocation<Tag=(),Extra=()> {     pub extra: Extra, } +#[derive(Clone, Debug, Eq, PartialEq, PartialOrd, Ord, Hash, RustcEncodable, RustcDecodable)]+pub struct AllocationBytes {+    /// The actual bytes of the allocation.+    /// Note that the bytes of a pointer represent the offset of the pointer+    pub bytes: Vec<u8>,+    /// Denotes undefined memory. Reading from undefined memory is forbidden in miri

This is not true, memcpy of undefined memory is allowed. Also the important part is that it's forbidden in Rust.

I think we should state this positively: "Denotes which part of this allocation is initialized". Maybe it should even be renamed to InitMask?

HeroicKatora

comment created time in 32 minutes

Pull request review commentrust-lang/rust

[WIP] Elide allocation of uninit static

 use std::borrow::Cow;  #[derive(Clone, Debug, Eq, PartialEq, PartialOrd, Ord, Hash, RustcEncodable, RustcDecodable)] pub struct Allocation<Tag=(),Extra=()> {-    /// The actual bytes of the allocation.-    /// Note that the bytes of a pointer represent the offset of the pointer-    pub bytes: Vec<u8>,+    /// The byte allocation and definedness.+    /// Bytes of fully undefined allocations are allocated lazily on potentially mutable changes.+    pub alloc: Option<AllocationBytes>,     /// Maps from byte addresses to extra data for each pointer.     /// Only the first byte of a pointer is inserted into the map; i.e.,     /// every entry in this map applies to `pointer_size` consecutive bytes starting     /// at the given offset.     pub relocations: Relocations<Tag>,

Relocations should also move into alloc then, no point in keeping them when the allocation is fully uninitialized.

HeroicKatora

comment created time in 33 minutes

Pull request review commentrust-lang/rust

rustc_typeck: improve diagnostics for -> _ fn return type

 error[E0121]: the type placeholder `_` is not allowed within types on item signa   --> $DIR/E0121.rs:1:13    | LL | fn foo() -> _ { 5 }-   |             ^ not allowed in type signatures+   |             ^+   |             |+   |             not allowed in type signatures+   |             help: replace `_` with the correct return type: `i32`  error[E0121]: the type placeholder `_` is not allowed within types on item signatures

Yes, basically delegate to the AST representation of const $name: _ = $expr; and make sure to error in the parser.

lundibundi

comment created time in 33 minutes

Pull request review commentrust-lang/rust

[WIP] Elide allocation of uninit static

 use std::borrow::Cow;  #[derive(Clone, Debug, Eq, PartialEq, PartialOrd, Ord, Hash, RustcEncodable, RustcDecodable)] pub struct Allocation<Tag=(),Extra=()> {-    /// The actual bytes of the allocation.-    /// Note that the bytes of a pointer represent the offset of the pointer-    pub bytes: Vec<u8>,+    /// The byte allocation and definedness.+    /// Bytes of fully undefined allocations are allocated lazily on potentially mutable changes.+    pub alloc: Option<AllocationBytes>,     /// Maps from byte addresses to extra data for each pointer.     /// Only the first byte of a pointer is inserted into the map; i.e.,     /// every entry in this map applies to `pointer_size` consecutive bytes starting     /// at the given offset.     pub relocations: Relocations<Tag>,-    /// Denotes undefined memory. Reading from undefined memory is forbidden in miri-    pub undef_mask: UndefMask,+    /// The size of the allocation.+    /// Used after initialiation of an undef region that is not allocated.

I find this comment confusing. What about "If alloc is not None, this is the same as bytes.len()"?

HeroicKatora

comment created time in 34 minutes

Pull request review commentrust-lang/rust

[WIP] Elide allocation of uninit static

 use std::borrow::Cow;  #[derive(Clone, Debug, Eq, PartialEq, PartialOrd, Ord, Hash, RustcEncodable, RustcDecodable)] pub struct Allocation<Tag=(),Extra=()> {-    /// The actual bytes of the allocation.-    /// Note that the bytes of a pointer represent the offset of the pointer-    pub bytes: Vec<u8>,+    /// The byte allocation and definedness.+    /// Bytes of fully undefined allocations are allocated lazily on potentially mutable changes.

"potentially mutable changes"?

HeroicKatora

comment created time in 35 minutes

issue commentrust-lang/miri

`cargo miri test` does not run doc-tests

Hm, that raises the interesting question how cargo miri test would invoke rustdoc. Probably through cargo test? Can we do that targeting just the doctests of a particular binary?

Currently I wouldn't know how cargo miri test can get those flags; for the binaries we run we get them from cargo as well (cargo miri sets itself into the RUSTC env var so that cargo calls it with all the right flags and it just has to forward them).

RalfJung

comment created time in 36 minutes

issue commentrust-lang/unsafe-code-guidelines

Layout of repr(C) unions has padding

I do not understand why this is a consequence. Your summary (and thanks for the writeup!) says that "Rust and GCC pass the bottom 32-bits". So it is possible to implement this in a way that preserves all bits. Correct?

So that's a good question. Consider this:

#[repr(C)] union U { x: (u8, u32 ) }
extern "C" {
      fn foo() -> U;
}

If the foo implementation is C code compiled with a C compiler, then the padding bytes of the returned U will probably be undef because the C compiler does not need to put anything initialized in there.

OTOH, if we were to somehow make Rust to always copy padding bytes for repr(C) unions, and enforce that in extern "C" fn foo() -> U { ... } function definitions, then those padding bytes could be initialized to something meaningful.

We can't tell whether the code at the other side is Rust or C, so if we want to be able to treat a repr(C) union as a bag of bytes here, we would always need to freeze the union when doing FFI.

I tend to think that an extern "C" declaration should be assumed to follow C rules (e.g. no panics), and that most people use them for interfacing with C, and that we should be able to optimize according to those rules. In this particular case, it would mean that we don't have to copy padding when dealing with these unions, however minor this optimization is for this example, or even in general.

gnzlbg

comment created time in 37 minutes

push eventrust-lang/crates.io-index

bors

commit sha 18bef659caf4ae0c81e82ba35c46e4456224ae9c

Updating crate `oasis-build#0.2.0`

view details

push time in 40 minutes

issue commentrust-lang/miri

`cargo miri test` does not run doc-tests

Cargo hands rustdoc all the --extern flags it needs when running rustdoc --test from cargo test, so presumably that information would be present in the crate's metadata.

RalfJung

comment created time in 41 minutes

Pull request review commentrust-lang/unsafe-code-guidelines

Guarantee the layout of structs with a single non-zero-sized field

 compiler will not reorder it, to allow for the possibility of unsizing. E.g., `struct Foo { x: u16, y: u32 }` and `struct Foo<T> { x: u16, y: T }` where `T = u32` are not guaranteed to be identical. +#### Default layout of structs with a single non-zero-sized field++The default layout of structs with a single non-zero-sized field is the same as+the layout of that field if the alignment requirement of all other fields is 1.

The obvious alternative is 1-ZST. "One-aligned zero-sized type" works better than "zero-sized type, 1-aligned".

gnzlbg

comment created time in 43 minutes

Pull request review commentrust-lang/unsafe-code-guidelines

Guarantee the layout of structs with a single non-zero-sized field

 compiler will not reorder it, to allow for the possibility of unsizing. E.g., `struct Foo { x: u16, y: u32 }` and `struct Foo<T> { x: u16, y: T }` where `T = u32` are not guaranteed to be identical. +#### Default layout of structs with a single non-zero-sized field++The default layout of structs with a single non-zero-sized field is the same as+the layout of that field if the alignment requirement of all other fields is 1.

ZSOAT was meant as a proposal that is so bad that we clearly cannot use it. :)

ZST1/ZST4 sounds good to me! The general ZSTN looks a bit funny though, ZST-N would be clearer, so maybe it should be ZST-1 then?

gnzlbg

comment created time in 43 minutes

issue commentrust-lang/rust

ICE on generator type check with a must_use type

Having used https://github.com/jethrogb/rust-reduce on the code and with a little manual intervention the ICE is now this:

#![feature(async_await)]
use std::future::Future;

pub trait T {
    type Future: Future<Output = String>;
    fn bar() -> Self::Future;
}
pub async fn foo<S>() where S: T {
    S::bar().await;
    S::bar().await;
}

Replacing Output=String with Output=i32 and it passes on that version of rustc.

LucioFranco

comment created time in 43 minutes

Pull request review commentrust-lang/unsafe-code-guidelines

Resolve layout of single variant enums

 enum Enum1<T> { } ``` -## Unresolved questions- ### Layout of single variant enums -[Issue #79.](https://github.com/rust-rfcs/unsafe-code-guidelines/issues/79)--Enums that contain a **single variant** and which do not have an-explicit `#[repr]` annotation are an important special case. Since-there is only a single variant, the enum must be instantiated with-that variant, which means that the enum is in fact equivalent to a-struct. The question then is to what extent we should **guarantee**-that the two share an equivalent layout, and also how to define the-interaction with uninhabited types.+**Single variant data-carrying*** enums without a `repr()` annotation have the+same layout as the variant field. **Single variant fieldless** enums have the+same layout as a unit struct. -As presently implemented, the compiler will use the same layout for-structs and for single variant enums (as long as they do not have a-`#[repr]` annotation that overrides that choice). So, for example, the-struct `SomeStruct` and the enum `SomeEnum` would have an equivalent-layout ([playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=3697ac684c3d021892694956df957653)):+Here:  ```rust-struct SomeStruct;-enum SomeEnum {-  SomeVariant,-}-+# use std::mem::{size_of, align_of};+struct UnitStruct;+enum SingleVariantFieldless { FieldlessVariant } # fn main() {-# use std::mem;-let x = SomeStruct;-let y = SomeEnum::SomeVariant;-assert_eq!(-    mem::size_of_val(&x), -    mem::size_of_val(&y),-    "types have different sizes",-);-println!("types both have size {}", std::mem::size_of_val(&x));+assert_eq!(size_of::<SingleVariantFieldless>(), size_of::<UnitStruct>());+assert_eq!(align_of::<SingleVariantFieldless>(), align_of::<UnitStruct>());+// assert_eq!(call_abi_of::<SingleVariantFieldless>(), call_abi_of::<UnitStruct>());+// assert_eq!(niches_of::<SingleVariantFieldless>(), niches_of::<UnitStruct>()); # } ``` -Similarly, the struct `SomeStruct` and the enum `SomeVariant` in this-example would also be equivalent in their layout-([playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=924724764419f846c788a8763da45992)):+the single-variant fieldless enum `SingleVariantFieldless` has the same layout+as `UnitStruct`.++Here:   ```rust+# use std::mem::{size_of, align_of}; struct SomeStruct { x: u32 }-enum SomeEnum {-  SomeVariant { x: u32 },+enum SingleVariantDataCarrying {+  DataCarryingVariant(SomeStruct), }- # fn main() {-# use std::mem;-let x = SomeStruct { x: 22 };-let y = SomeEnum::SomeVariant { x: 22 };-assert_eq!(-    mem::size_of_val(&x), -    mem::size_of_val(&y),-    "types have different sizes",-);-println!("types both have size {}", mem::size_of_val(&x));-}+# assert_eq!(size_of::<SingleVariantDataCarrying>(), size_of::<SomeStruct>());+# assert_eq!(align_of::<SingleVariantDataCarrying>(), align_of::<SomeStruct>());+# } ``` -In fact, the compiler will use this optimized layout even for enums-that define multiple variants, as long as all but one of the variants-is uninhabited-([playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=3cc1484c5b91097f3dc2015b7c207a0e)):+the single-variant data-carrying enum `SingleVariantDataCarrying` has the same+layout as `SomeStruct`.++### Layout of multi-variant enums with one inhabited variant++The layout of **multi-variant** enums with **one inhabited variant** is the same

There are at least three different kinds of "inhabited":

  • Type tas a call ABI other than Uninhabited.
  • The type's validity invariant is satisfiable.
  • The type's safety invariant is satisfiable.

So, the term is ambiguous without further clarification.

gnzlbg

comment created time in an hour

push eventrust-lang/miri

Ralf Jung

commit sha 95e6e671bf2993ec51b778a0531bf393c575a7e0

fix compile-fail tests for latest rustc

view details

bors

commit sha fe607596a619ee59c96ac52ac2d1408f4a7568af

Auto merge of #843 - RalfJung:rustup, r=RalfJung fix compile-fail tests for latest rustc

view details

push time in an hour

PR merged rust-lang/miri

fix compile-fail tests for latest rustc
+3 -3

4 comments

3 changed files

RalfJung

pr closed time in an hour

pull request commentrust-lang/miri

fix compile-fail tests for latest rustc

:sunny: Test successful - checks-travis, status-appveyor Approved by: RalfJung Pushing fe607596a619ee59c96ac52ac2d1408f4a7568af to master... <!-- homu: {"type":"BuildCompleted","approved_by":"RalfJung","base_ref":"master","builders":{"status-appveyor":"https://ci.appveyor.com/project/rust-lang-libs/miri/builds/26020836","checks-travis":"https://travis-ci.com/rust-lang/miri/builds/119348008"},"merge_sha":"fe607596a619ee59c96ac52ac2d1408f4a7568af"} -->

RalfJung

comment created time in an hour

push eventrust-lang/crates.io-index

bors

commit sha 1d10e5b89c0259e1303ffda03203b054bc7d5eb6

Updating crate `serde_test#1.0.95`

view details

push time in an hour

push eventrust-lang/crates.io-index

bors

commit sha 6f2679dd9bf344f8908bc6ffcd3fb70fa2401234

Updating crate `serde_derive#1.0.95`

view details

push time in an hour

push eventrust-lang/crates.io-index

bors

commit sha f839720dd85f3f4aa925bf30d53d3031e4cce9fa

Updating crate `serde#1.0.95`

view details

push time in an hour

Pull request review commentrust-lang/unsafe-code-guidelines

Resolve layout of single variant enums

 enum Enum1<T> { } ``` -## Unresolved questions- ### Layout of single variant enums -[Issue #79.](https://github.com/rust-rfcs/unsafe-code-guidelines/issues/79)--Enums that contain a **single variant** and which do not have an-explicit `#[repr]` annotation are an important special case. Since-there is only a single variant, the enum must be instantiated with-that variant, which means that the enum is in fact equivalent to a-struct. The question then is to what extent we should **guarantee**-that the two share an equivalent layout, and also how to define the-interaction with uninhabited types.+**Single variant data-carrying*** enums without a `repr()` annotation have the+same layout as the variant field. **Single variant fieldless** enums have the+same layout as a unit struct. -As presently implemented, the compiler will use the same layout for-structs and for single variant enums (as long as they do not have a-`#[repr]` annotation that overrides that choice). So, for example, the-struct `SomeStruct` and the enum `SomeEnum` would have an equivalent-layout ([playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=3697ac684c3d021892694956df957653)):+Here:  ```rust-struct SomeStruct;-enum SomeEnum {-  SomeVariant,-}-+# use std::mem::{size_of, align_of};+struct UnitStruct;+enum SingleVariantFieldless { FieldlessVariant } # fn main() {-# use std::mem;-let x = SomeStruct;-let y = SomeEnum::SomeVariant;-assert_eq!(-    mem::size_of_val(&x), -    mem::size_of_val(&y),-    "types have different sizes",-);-println!("types both have size {}", std::mem::size_of_val(&x));+assert_eq!(size_of::<SingleVariantFieldless>(), size_of::<UnitStruct>());+assert_eq!(align_of::<SingleVariantFieldless>(), align_of::<UnitStruct>());+// assert_eq!(call_abi_of::<SingleVariantFieldless>(), call_abi_of::<UnitStruct>());+// assert_eq!(niches_of::<SingleVariantFieldless>(), niches_of::<UnitStruct>());

The fact that they are commented out could also be interpreted as "this does not currently hold", as one would do in a test suite.

So, it should be made clearer that they are commented out just because the methods don't exist. Probably stating "these things are the same" as Rust asserts is not the clearest way anyway, and it is very verbose.

gnzlbg

comment created time in an hour

issue commentrust-lang/rust

Tracking issue for RFC 2645, "Transparent Unions and Enums"

What remains on-topic here I think is the following observation: we cannot both support repr(transparent) and say that non-repr(C)-unions are bags of bits. Correct?

Depends on whether we can make repr(C) unions bags of bits. These aren't bag of bits in C, but maybe there is a way to make them bag of bits in Rust ?

Centril

comment created time in an hour

issue commentrust-lang/miri

`cargo miri test` does not run doc-tests

If there were some flag we could provide to just save off all the doctests as standalone rust files, would that be enough to allow miri to attempt to build them?

I guess we could make cargo miri test pick them up and run them all through Miri. The hard part would be to figure out the right command-line flags to get all the dependencies to work, but I am not sure if rustdoc can even help there?

RalfJung

comment created time in an hour

startedrust-lang/rust

started time in an hour

issue commentrust-lang/miri

`cargo miri test` does not run doc-tests

If there were some flag we could provide to just save off all the doctests as standalone rust files, would that be enough to allow miri to attempt to build them? They're meant to be compiled as binaries and link against the regular crate and its dependency tree.

RalfJung

comment created time in an hour

pull request commentrust-lang/rust

rustc: don't use Abi::ScalarPair for unions when padding is involved.

but we should pick there the semantics that make most sense for Rust first, and worry about how to implement them later.

I'd love to do that, and fight fiercely for "bag of bits no matter the repr", but that seems to me like ignoring reality if we come up with an unimplementable semantics...

eddyb

comment created time in an hour

issue commentrust-lang/miri

`cargo miri test` does not run doc-tests

Yeah, now I see what @QuietMisdreavus meant by librustc_interface -- it does not call the rustc binary, it calls the rustc library.

The "easiest" way to get Miri into this would be to provide a way to call some binary instead, but I am not sure if that is feasible.

RalfJung

comment created time in an hour

pull request commentrust-lang/cargo

Fix some issues with absolute paths in dep-info files.

Ah, sure, that makes sense. I'll work on making that happen -- I think from a rustc perspective a -Z flag should be fairly easy to implement.

ehuss

comment created time in an hour

issue commentrust-lang/unsafe-code-guidelines

Validity of fat pointer metadata

Nit: The issue title talks about references, but the text (and Weak::new discussion) about pointers more generally, which is it?

Good point! That actually explains part of my confusion. I updated text and title.

RalfJung

comment created time in an hour

pull request commentrust-lang/cargo

Fix some issues with absolute paths in dep-info files.

Perhaps I misunderstood -- I thought this PR was necessary to get rust-lang/rust#61727 working properly, even with modifications to rustbuild? In that case it seems we need to backport to beta to get rustbuild working. I'd be happy to do the legwork adding unstable flags or similar wherever necessary!

It is required, but from my perspective I feel it is too risky to backport this to beta. I would prefer to wait for the next release cycle before turning 61727 on. If you add a -Z flag to 61727, then you can land it now and we can experiment more with testing it (by setting cargo in config.toml to a version from nightly). And then in 1.39 we can remove the -Z flag and make it the default. Or we can just leave 61727 open until 1.39.

It's unfortunate to delay 4 more weeks, but I don't want to chase potential new issues on beta.

ehuss

comment created time in an hour

pull request commentrust-lang/rust

rustc: don't use Abi::ScalarPair for unions when padding is involved.

Without this PR, #[repr(Rust)] union U { x: (u8, u32) } has 3 bytes of padding that are not copied when the union is copied / moved.

This means that code that assumes that these bytes are copied on move is broken.

This is more restrictive, than copying these bytes, and I think it is the conservative thing to do until https://github.com/rust-lang/unsafe-code-guidelines/issues/156 is resolved. That is, I'd rather not merge this.


For #[repr(C)] union U { x: (u8, u32) }, the issue was trickier. C does not copy the padding, so in a round trip Rust->C->Rust it cannot be preserved. The open question is whether it is even possible to try to copy the padding here in the Rust side, e.g., when dealing with extern "C" fn foo(U) -> U { ... } definitions, that are potentially only ever called from Rust code. I recall @eddyb mentioning that the calling convention should not interact with this, and that maybe we could give these the same layout as a [u8; size_of::<U>()] to work around that, but I don't recall the details of why this was hard to achieve.

I think all of this should inform https://github.com/rust-lang/unsafe-code-guidelines/issues/156 , but we should pick there the semantics that make most sense for Rust first, and worry about how to implement them later.

eddyb

comment created time in an hour

issue commentrust-lang/miri

`cargo miri test` does not run doc-tests

The compilation of tests seems to be performed at https://github.com/rust-lang/rust/blob/17e62f77f954bed97aae839624bfd6dd68342daf/src/librustdoc/test.rs#L181.

RalfJung

comment created time in an hour

push eventrust-lang/crates.io-index

bors

commit sha c0736d94f0658afca2816ed6927c1bfa19a6d708

Updating crate `oasis-std#0.2.0`

view details

push time in an hour

issue commentrust-lang/miri

`cargo miri test` does not run doc-tests

How open would the rustdoc team be to provide a way for Miri to run the extracted tests, and what would be the preferred way of achieving that (librustdoc vs controlling what happens after extraction)?

For me it seems like the second option is the simpler one.

RalfJung

comment created time in an hour

issue commentrust-lang/unsafe-code-guidelines

Layout of uninhabited types

I think for Rust, "uninhabited" is a particular "call ABI": https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/layout/enum.Abi.html#variant.Uninhabited.

We should describe when types are considered uninhabited

Agreed. We should also define the term precisely, because there are many kinds of "uninhabited" in Rust. Some types have "uninhabited" call ABI, some have no value satisfying the validity invariant, some have no value satisfying the safety invariant.

gnzlbg

comment created time in an hour

push eventrust-lang/crates.io-index

bors

commit sha 10192b39d7bcb94ff0c465a5521b5cea805080e2

Updating crate `oasis-test#0.2.0`

view details

push time in an hour

push eventrust-lang/crates.io-index

bors

commit sha b37df1639f5896d8a09ce9b8562ab9fa298bf520

Updating crate `filecoin-proofs-ffi#0.5.0`

view details

push time in an hour

issue commentrust-lang/miri

`cargo miri test` does not run doc-tests

@rust-lang/rustdoc, can rustdoc be used as a library (not a driver) to extract the doctests without running them?

Unfortunately, librustdoc was taken out of the sysroot a while back, and i don't think we auto-publish the source for that as a crate either, so there's not really an easy solution for that. Rustdoc itself doesn't really provide functionality to only save off the extracted/converted doctest, either.

Or, alternatively, can we set some environment variable to make rustdoc call miri instead of calling rustc and running the binary on each test after extraction?

Same response - unless the test is manually marked as ignore (or given some non-rust language string) in the source, rustdoc will always run the converted doctest through rustc via the librustc_interface interface. There's an open PR to run the compiled binaries through a "test runner", but it doesn't sound like that will help either.

RalfJung

comment created time in an hour

startedrust-lang/miri

started time in an hour

issue commentrust-lang/rust

Tracking issue for RFC 2645, "Transparent Unions and Enums"

I don't know how this information affects the guarantees that we could make about the layout of repr(Rust) unions

What remains on-topic here I think is the following observation: we cannot both support repr(transparent) and say that non-repr(C)-unions are bags of bits. Correct?

Centril

comment created time in an hour

push eventrust-lang/crates.io-index

bors

commit sha 74fd5d7856632ac014241ad3d155b7d93b81f694

Updating crate `memchain#0.2.1`

view details

push time in an hour

push eventrust-lang/crates.io-index

bors

commit sha 5d80f2df4397feaeeebf70ee0dc494533adb7975

Updating crate `oasis-macros#0.2.0`

view details

push time in an hour

Pull request review commentrust-lang/rust

rustc_typeck: improve diagnostics for -> _ fn return type

 error[E0121]: the type placeholder `_` is not allowed within types on item signa   --> $DIR/E0121.rs:1:13    | LL | fn foo() -> _ { 5 }-   |             ^ not allowed in type signatures+   |             ^+   |             |+   |             not allowed in type signatures+   |             help: replace `_` with the correct return type: `i32`  error[E0121]: the type placeholder `_` is not allowed within types on item signatures

Help for const FOO = 42; looks nice, that's how I usually forget about it in const's, though I'm not sure what'd be the correct parser recovery, replacing the type with Infer and then failing here with proper help?

lundibundi

comment created time in an hour

push eventrust-lang/crates.io-index

bors

commit sha fd5c0f1b72b0e434bebc0d739bf88ac5189aeab3

Updating crate `oasis-rpc#0.1.0`

view details

push time in an hour

issue commentrust-lang/miri

`cargo miri test` does not run doc-tests

Or, alternatively, can we set some environment variable to make rustdoc call miri instead of rustc on each test after extraction?

RalfJung

comment created time in an hour

push eventrust-lang/crates.io-index

bors

commit sha 77c54440c095cb82c3330e7f77920c872fc092d9

Updating crate `oasis-types#0.2.0`

view details

push time in an hour

Pull request review commentrust-lang/unsafe-code-guidelines

Guarantee the layout of some unions having a single non-zero-sized field

 not to change until an RFC ratifies them.  [#13]: https://github.com/rust-rfcs/unsafe-code-guidelines/issues/13 -The only degree of freedom the compiler has when computing the layout of a union-like+### Layout of individual union fields -```rust,ignore-union U { f1: T1, f2: T2 }+The layout of each union field is determined by its type. ++<details><summary><b>Rationale</b></summary>++This is required to allow creating references to union fields:++```rust+# fn main() { unsafe {+# #[derive(Copy, Clone)]+struct T1;+union U { f1: T1 }+let u = U { f1: T1 };+let t1: &T1 = &u.f1;+// &T1 works for all references+# }}+```+</details>++### Unions with default layout ("`repr(Rust)`")++**The default layout of unions is**, in general, **not specified.** ++<details><summary><b>Rationale</b></summary>++As of this writing, we want to keep the option of using non-zero offsets open+for the future; whether this is useful depends on what exactly the+compiler-assumed invariants about union contents are. This might become clearer+after the validity of unions+([unsafe-code-guidelines/73](https://github.com/rust-lang/unsafe-code-guidelines/issues/73))+is settled.++Even if the offsets happen to be all 0, there might still be differences in the+function call ABI.  If you need to pass unions by-value across an FFI boundary,+you have to use `#[repr(C)]`.++</details>++#### Layout of unions with a single non-zero-sized field++The layout of unions with a single non-zero-sized field is the same as the+layout of that field if:++* that field has no padding bits, and

We have not defined padding (what it is, how it behaves, where it occurs in which types) anywhere, and IMO it is not part of layout. So I feel like we are getting a little ahead of ourselves here.

Padding is IMO part of the value representation of a type; no interpretation of layout (size, align, niche, call ABI, field offsets) really includes "padding". For structs it naturally emerges as the "gaps between" fields, for enums I have no idea and for unions I am confused. ;)

gnzlbg

comment created time in an hour

issue commentrust-lang/rust

Add IoSlice advance or similiar method

Looking for some feedback as to whether this would be accepted.

Thomasdezeeuw

comment created time in an hour

pull request commentrust-lang/rust

rustc: don't use Abi::ScalarPair for unions when padding is involved.

I honestly don't know.^^ @eddyb @gnzlbg what difference does this make for https://github.com/rust-lang/unsafe-code-guidelines/issues/156 ?

eddyb

comment created time in an hour

pull request commentrust-lang/unsafe-code-guidelines

Guarantee the layout of some unions having a single non-zero-sized field

all zero-sized fields have an alignment requirement of 1.

This is another place where we should use the "ZST1" terminology.

gnzlbg

comment created time in an hour

push eventrust-lang/crates.io-index

bors

commit sha 599c9c1ea3e8ee889877257752e94e7e4d39c9a0

Updating crate `r1cs#0.1.5`

view details

push time in an hour

Pull request review commentrust-lang/unsafe-code-guidelines

Detail layout of repr(C) unions

 contents are. Even if the offsets happen to be all 0, there might still be differences in the function call ABI.  If you need to pass unions by-value across an FFI boundary, you have to use `#[repr(C)]`.++### Layout of `repr(C)` unions++The layout of `repr(C)` unions follows the C layout scheme. Per sections+[6.5.8.5] and [6.7.2.1.16] of the C11 specification, this means that the offset+of every field is 0. Unsafe code can cast a pointer to the union to a field type+to obtain a pointer to any field, and vice versa. ++[6.5.8.5]: http://port70.net/~nsz/c/c11/n1570.html#6.5.8p5+[6.7.2.1.16]: http://port70.net/~nsz/c/c11/n1570.html#6.7.2.1p16++Since all fields are at offset 0, this implies that `repr(C)` unions do not have+padding before or in-between their fields. They can, however, have trailing+padding (see next example).++Union fields of zero-size participate in the layout computation of the union. For example:

This is just a consequence of prior statements, not a new normative clause, right? It should be marked as that.

gnzlbg

comment created time in an hour

issue openedrust-lang/rust

Add IoSlice advance or similiar method

Writing https://github.com/rust-lang-nursery/futures-rs/pull/1741 I needed to resort to unsafe code to change the underlying slice in IoSlice (and IoSliceMut). I'm missing a method that can change the underlying slice. @Nemo157 said that I should open an issue.

Current idea would be something like Buf::advance from the bytes crate.

impl IoSlice {
    // Advance the internal cursors of the slice by `n` bytes.
    fn advance(&mut self, n: usize) {
        // ..
    }
}

created time in an hour

Pull request review commentrust-lang/unsafe-code-guidelines

Detail layout of repr(C) unions

 contents are. Even if the offsets happen to be all 0, there might still be differences in the function call ABI.  If you need to pass unions by-value across an FFI boundary, you have to use `#[repr(C)]`.++### Layout of `repr(C)` unions++The layout of `repr(C)` unions follows the C layout scheme. Per sections+[6.5.8.5] and [6.7.2.1.16] of the C11 specification, this means that the offset+of every field is 0. Unsafe code can cast a pointer to the union to a field type+to obtain a pointer to any field, and vice versa. ++[6.5.8.5]: http://port70.net/~nsz/c/c11/n1570.html#6.5.8p5+[6.7.2.1.16]: http://port70.net/~nsz/c/c11/n1570.html#6.7.2.1p16++Since all fields are at offset 0, this implies that `repr(C)` unions do not have+padding before or in-between their fields. They can, however, have trailing+padding (see next example).

Padding isn't really part of the layout, it is part of the "value representation". So I am not sure if this fits here.

gnzlbg

comment created time in an hour

issue commentrust-lang/unsafe-code-guidelines

Layout of repr(C) unions has padding

That is, repr(C) unions are not and cannot be just "bags of bits" where one could write to any bit, and that bit value would need to be preserved on copy / move / pass-by-value.

I do not understand why this is a consequence. Your summary (and thanks for the writeup!) says that "Rust and GCC pass the bottom 32-bits". So it is possible to implement this in a way that preserves all bits. Correct?

Note: I am not concerned about bits getting preserved when Rust calls a C function and then C passes data back to Rust. At that point, C rules apply. But I am concerned about the case where Rust code calls an extern "C" function that is also implemented in Rust.

gnzlbg

comment created time in an hour

issue commentrust-lang/miri

`cargo miri test` does not run doc-tests

@rust-lang/rustdoc, can rustdoc be used as a library (not a driver) to extract the doctests without running them?

RalfJung

comment created time in an hour

push eventrust-lang/cargo

Alex Crichton

commit sha ce04a53a3e0c5a16fb0d99a32587b2b748a92bc3

Set up CI with Azure Pipelines

view details

push time in an hour

Pull request review commentrust-lang/rust

Change untagged_unions to not allow union fields with drop

 fn check_union(tcx: TyCtxt<'_>, id: hir::HirId, span: Span) {     def.destructor(tcx); // force the destructor to be evaluated     check_representable(tcx, span, def_id);     check_transparent(tcx, span, def_id);+    check_union_fields(tcx, span, def_id);     check_packed(tcx, span, def_id); } +/// When the `#![feature(untagged_unions)]` gate is active,+/// check that the fields of the `union` does not contain fields that need dropping.+fn check_union_fields(tcx: TyCtxt<'_>, _: Span, item_def_id: DefId) -> bool {+    // Without the feature we check Copy types only later+    if !tcx.features().untagged_unions {+        return true;+    }+    let item_type = tcx.type_of(item_def_id);+    if let ty::Adt(def, substs) = item_type.sty {+        if def.is_union() {

So type_of can be called on a union item and then returns that union?

I wouldn't call that the "type of" the item, that's why I am confused. The type of union Foo { ... } should be Type or so.

SimonSapin

comment created time in an hour

push eventrust-lang/crates.io-index

bors

commit sha 3cfee202cdbadabd56790359d91bdf616b70a953

Updating crate `trybuild#1.0.8`

view details

push time in an hour

pull request commentrust-lang/rust

Add APIs for uninitialized Box, Rc, and Arc. (Plus get_mut_unchecked)

But the point of Box::new_uninit is that there is no such move/copy at all in the first place.

My thinking was that a codegen test would demonstrate that this is indeed the case.

But if you think the chances of anyone every accidentally changing Box::new_uninit to have a copy that needs eliding are slim, I am fine with not adding a test.

SimonSapin

comment created time in an hour

Pull request review commentrust-lang/rust

Add APIs for uninitialized Box, Rc, and Arc. (Plus get_mut_unchecked)

 impl<T> Rc<T> {     } } +impl<T> Rc<[T]> {+    /// Construct a new reference-counted slice with uninitialized contents.+    ///+    /// # Examples+    ///+    /// ```+    /// #![feature(new_uninit)]+    /// #![feature(get_mut_unchecked)]+    ///+    /// use std::rc::Rc;+    ///+    /// let mut values = Rc::<[u32]>::new_uninit_slice(3);+    ///+    /// let values = unsafe {+    ///     // Deferred initialization:+    ///     Rc::get_mut_unchecked(&mut values)[0].as_mut_ptr().write(1);+    ///     Rc::get_mut_unchecked(&mut values)[1].as_mut_ptr().write(2);+    ///     Rc::get_mut_unchecked(&mut values)[2].as_mut_ptr().write(3);+    ///+    ///     values.assume_init()+    /// };+    ///+    /// assert_eq!(*values, [1, 2, 3])+    /// ```+    #[unstable(feature = "new_uninit", issue = "0")]+    pub fn new_uninit_slice(len: usize) -> Rc<[mem::MaybeUninit<T>]> {+        let data_layout = Layout::array::<mem::MaybeUninit<T>>(len).unwrap();+        let (layout, offset) = Layout::new::<RcBox<()>>().extend(data_layout).unwrap();

I see.

Please add a comment explaining why using () for the type inside RcBox makes sense here.

SimonSapin

comment created time in an hour

Pull request review commentrust-lang/rust

Add APIs for uninitialized Box, Rc, and Arc. (Plus get_mut_unchecked)

 impl<T: ?Sized> Rc<T> {     pub fn get_mut(this: &mut Self) -> Option<&mut T> {         if Rc::is_unique(this) {             unsafe {-                Some(&mut this.ptr.as_mut().value)+                Some(Rc::get_mut_unchecked(this))             }         } else {             None         }     } +    /// Returns a mutable reference to the inner value,+    /// without any check.+    ///+    /// See also [`get_mut`], which is safe and does appropriate checks.+    ///+    /// [`get_mut`]: struct.Rc.html#method.get_mut+    ///+    /// # Safety+    ///+    /// There must be no other `Rc` or [`Weak`] pointers to the same value.+    /// This is the case for example immediately after `Rc::new`.

Oh I see you demand this being the only Rc at all. Why that? If the others are all "not used", there shouldn't be a problem...

SimonSapin

comment created time in an hour

more