profile
viewpoint
Felix S Klock II pnkfelix Massachusetts, USA

pnkfelix/boxdraw-rs 2

Library for drawing ASCII art rectangles

Manishearth/rust 1

a safe, concurrent, practical language

pnkfelix/BinFiles 1

Little scripts that my ConfigFiles and DotFiles sometimes reference. Meant to be alias of ~/bin/

pnkfelix/ack 0

A replacement for grep for programmers

pnkfelix/ack2 0

ack 2.0

pnkfelix/add3 0

A demo project for illustrating dependency handling in Cargo

pnkfelix/add6 0

Toy crate that depends on past version of add3 crate.

pnkfelix/agents 0

Agent based simulation

pnkfelix/alexa-rs 0

Rust library for building Alexa skills

issue commentrust-lang/rust

async-std docs no longer build on recent nightlies

@jyn514 I just reviewed it. I assume the rustdoc team is onboard with the other changes it makes. (Certainly ignoring the resolution errors in those cases seems to be in line with what rustdoc does elsewhere at this point.)

yoshuawuyts

comment created time in 12 hours

pull request commentrust-lang/rust

Fix async-std by special-casing rustdoc in typeck

@bors rollup=never

jyn514

comment created time in 12 hours

pull request commentrust-lang/rust

Fix async-std by special-casing rustdoc in typeck

@bors r+

jyn514

comment created time in 12 hours

issue commentrust-lang/rust

async-std docs no longer build on recent nightlies

Another option since beta is coming up in ~3 weeks is to just eat the ICE and say that error -> ICE is better than working code to error :/ and then go back and fix the root cause later. The only ICE is from invalid code:

https://github.com/rust-lang/rust/blob/0f5be70ea4c3ec4544cdeb80e3138832e15815f9/src/test/rustdoc-ui/infinite-recursive-type.rs#L1-L4

Also, keep in mind that yet another option, which I think is similar (but maybe less risky), is to revert PR# #73566, with the intention of relanding a more robust version of the change once the bugs are ironed out. (The presentation given in an earlier comment's discussion of a revert made it sound to me like it was a decision we'd have to live with forever, which is not the case as far as I can tell.)

  • (Of course, a revert of PR #73566 would mean suffering with the bugs that PR fixed for a bit longer on stable Rust.)
yoshuawuyts

comment created time in 3 days

pull request commentrust-lang/rust

[android] Add support for android's file descriptor ownership tagging to libstd.

discussed at today's T-compiler triage meeting.

The T-compiler members present at the meeting didn't have any strong opinions here. We agreed with @nikomatsakis that this warrants an FCP of some sort.

There was general consensus that this is, at its heart, a question of what the publicly specified API for Rust's File should be; the actual implementation code (which T-compiler maintains) is pretty trivial.

So we collectively decided at the meeting that while this should require an FCP, it should really solely require an FCP of the members of T-libs; T-compiler is going to opt out of participating in the FCP.

Thus, I am removing T-compiler, adding T-libs, and will go see if I can find a T-libs member to start up the FCP process for this PR.

jmgao

comment created time in 5 days

issue commentrust-lang/rust

error: could not compile `gkrust` since Rust 1.43 on SPARC Solaris

@zeldin okay, thanks. While I was hoping you'd have a smaller test case, the info you have given is nonetheless very helpful, since I think I'll have an easier time investigating this on PPC64, which is (I believe) a higher tier platform than SPARC Solaris. (At the very least, PPC64 has rustup-support...)

psumbera

comment created time in 6 days

startedshepmaster/rust

started time in 6 days

issue commentrust-lang/compiler-team

Discuss results of 2020 Contributor Survey

After learning that @mark-i-m may be unavailable on the scheduled August 14th, we decided to drop this meeting from the schedule; we'll try to get it into the next steering meeting cycle.

mark-i-m

comment created time in 6 days

issue commentrust-lang/rust

error: could not compile `gkrust` since Rust 1.43 on SPARC Solaris

@zeldin when you say "exactly the same problem", are you also attempting to build firefox and seeing this failure on teh gkrust crate?

Or do you have a smaller example test case to illustrate the problem on Linux/PPC64?

psumbera

comment created time in 6 days

push eventpnkfelix/pnkfelix.github.com

Felix S. Klock II

commit sha a0839d1d0a1644978ae4c052d067c2fbf3cb9cd6

updated resume.

view details

Felix S. Klock II

commit sha cabc2851699a4ddb3cda2f2c8acd6202c749be8f

updated generated resume.

view details

push time in 6 days

issue openedrust-lang/rust

support for boostraping on linux with `target = ["x86_64-unknown-linux-gnu", "x86_64-pc-windows-msvc"]`

Spawned off of https://zulip-archive.rust-lang.org/131828tcompiler/10990bootstraponlinuxwsupportforcrosscompilingtowind.html

After being reminded that one can install the stdlib for windows-msvc on a Linux host, that led me to ask whether one could build that artifact locally.

I tried to do so, but failed. You can see the results of some questions I asked and suggestions made in response at the above chat thread.

I don't think we need to make this support 100% transparent; e.g., it seems okay to force people to also specify that they don't want any dylibs, just rlibs. (Though it might be nice if there were a config.toml line for this rather than being forced to edit the Config.toml for a bunch of stdlib crates.)

In any case, I couldn't figure out how to get it to work, so this issue is meant to track effort to make this possible, and, if necessary, document what other changes a developer would need to make to their local setup (such as the aforementioned rlib thing) to get it going.

(The current roadblock is that the attempt to build compiler-builtins is trying to add /Zl as an option, which does not work on this host.)

<details> <summary>Click for more info on what changes I made locally to get as far as I could</summary>

% git diff --no-color && diff -u ../config.toml.example config.toml ; time ../x.py build --stage 1
diff --git a/library/std/Cargo.toml b/library/std/Cargo.toml
index 474765d8638..ed09312cb84 100644
--- a/library/std/Cargo.toml
+++ b/library/std/Cargo.toml
@@ -8,7 +8,7 @@ description = "The Rust Standard Library"
 edition = "2018"
 
 [lib]
-crate-type = ["dylib", "rlib"]
+crate-type = ["rlib"]
 
 [dependencies]
 alloc = { path = "../alloc" }
diff --git a/library/test/Cargo.toml b/library/test/Cargo.toml
index 7b76dc83aa2..42bfdb526c5 100644
--- a/library/test/Cargo.toml
+++ b/library/test/Cargo.toml
@@ -5,7 +5,7 @@ version = "0.0.0"
 edition = "2018"
 
 [lib]
-crate-type = ["dylib", "rlib"]
+crate-type = ["rlib"]
 
 [dependencies]
 cfg-if = { version = "0.1.8", features = ['rustc-dep-of-std'] }
diff --git a/src/bootstrap/sanity.rs b/src/bootstrap/sanity.rs
index f89bef50de9..f319d6194d5 100644
--- a/src/bootstrap/sanity.rs
+++ b/src/bootstrap/sanity.rs
@@ -217,13 +217,14 @@ pub fn check(build: &mut Build) {
             }
         }
 
-        if target.contains("msvc") {
+        if building_llvm && build.hosts.iter().any(|host|host.contains("msvc"))
+        {
             // There are three builds of cmake on windows: MSVC, MinGW, and
             // Cygwin. The Cygwin build does not have generators for Visual
             // Studio, so detect that here and error.
             let out = output(Command::new("cmake").arg("--help"));
             if !out.contains("Visual Studio") {
-                panic!(
+                eprintln!(
                     "
 cmake does not support Visual Studio generators.
 
--- ../config.toml.example	2020-08-04 11:10:07.940144080 -0400
+++ config.toml	2020-08-04 11:23:11.839046744 -0400
@@ -136,6 +136,7 @@
 #
 # Defaults to just the build triple
 #target = ["x86_64-unknown-linux-gnu"]
+target = ["x86_64-unknown-linux-gnu", "x86_64-pc-windows-msvc"]
 
 # Use this directory to store build artifacts.
 # You can use "$ROOT" to indicate the root of the git repository.
@@ -525,6 +526,7 @@
 # compiler itself. This is useful for building rustc on targets that normally
 # only use static libraries. If unset, the target's default linkage is used.
 #crt-static = false
+crt-static = true
 
 # The root location of the musl installation directory. The library directory
 # will also need to contain libunwind.a for an unwinding implementation. Note
Updating only changed submodules
Submodules updated in 0.03 seconds
    Finished dev [unoptimized + debuginfo] target(s) in 0.09s
Building stage0 std artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
    Finished release [optimized] target(s) in 0.08s
Copying stage0 std from stage0 (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu / x86_64-unknown-linux-gnu)
Building stage0 compiler artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
    Finished release [optimized] target(s) in 0.13s
Copying stage0 rustc from stage0 (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu / x86_64-unknown-linux-gnu)
Assembling stage1 compiler (x86_64-unknown-linux-gnu)
Building stage1 std artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
    Finished release [optimized] target(s) in 0.08s
Copying stage1 std from stage1 (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu / x86_64-unknown-linux-gnu)
Building stage1 std artifacts (x86_64-unknown-linux-gnu -> x86_64-pc-windows-msvc)
   Compiling core v0.0.0 (/home/pnkfelix/Dev/Mozilla/rust-xplat/library/core)
   Compiling libc v0.2.74
   Compiling compiler_builtins v0.1.32
The following warnings were emitted during compilation:

warning: cc: error: /Zl: No such file or directory

error: failed to run custom build command for `compiler_builtins v0.1.32`

Caused by:
  process didn't exit successfully: `/home/pnkfelix/Dev/Mozilla/rust-xplat/objdir/build/x86_64-unknown-linux-gnu/stage1-std/release/build/compiler_builtins-09dda507c59e8728/build-script-build` (exit code: 1)
  --- stdout
  cargo:rerun-if-changed=build.rs
  cargo:compiler-rt=/home/pnkfelix/.cargo/registry/src/github.com-1ecc6299db9ec823/compiler_builtins-0.1.32/compiler-rt
  cargo:rustc-cfg=feature="unstable"
  cargo:rerun-if-changed=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/absvdi2.c
  cargo:rustc-cfg=__absvdi2="optimized-c"
  cargo:rerun-if-changed=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/absvsi2.c
  cargo:rustc-cfg=__absvsi2="optimized-c"
  cargo:rerun-if-changed=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/absvti2.c
  cargo:rustc-cfg=__absvti2="optimized-c"
  cargo:rerun-if-changed=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/addvdi3.c
  cargo:rustc-cfg=__addvdi3="optimized-c"
  cargo:rerun-if-changed=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/addvsi3.c
  cargo:rustc-cfg=__addvsi3="optimized-c"
  cargo:rerun-if-changed=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/addvti3.c
  cargo:rustc-cfg=__addvti3="optimized-c"
  cargo:rerun-if-changed=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/clzdi2.c
  cargo:rustc-cfg=__clzdi2="optimized-c"
  cargo:rerun-if-changed=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/clzsi2.c
  cargo:rustc-cfg=__clzsi2="optimized-c"
  cargo:rerun-if-changed=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/clzti2.c
  cargo:rustc-cfg=__clzti2="optimized-c"
  cargo:rerun-if-changed=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/cmpdi2.c
  cargo:rustc-cfg=__cmpdi2="optimized-c"
  cargo:rerun-if-changed=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/cmpti2.c
  cargo:rustc-cfg=__cmpti2="optimized-c"
  cargo:rerun-if-changed=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/ctzdi2.c
  cargo:rustc-cfg=__ctzdi2="optimized-c"
  cargo:rerun-if-changed=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/ctzsi2.c
  cargo:rustc-cfg=__ctzsi2="optimized-c"
  cargo:rerun-if-changed=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/ctzti2.c
  cargo:rustc-cfg=__ctzti2="optimized-c"
  cargo:rerun-if-changed=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/divdc3.c
  cargo:rustc-cfg=__divdc3="optimized-c"
  cargo:rerun-if-changed=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/divsc3.c
  cargo:rustc-cfg=__divsc3="optimized-c"
  cargo:rerun-if-changed=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/divxc3.c
  cargo:rustc-cfg=__divxc3="optimized-c"
  cargo:rerun-if-changed=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/extendhfsf2.c
  cargo:rustc-cfg=__extendhfsf2="optimized-c"
  cargo:rerun-if-changed=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/ffsti2.c
  cargo:rustc-cfg=__ffsti2="optimized-c"
  cargo:rerun-if-changed=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/x86_64/floatdisf.c
  cargo:rustc-cfg=__floatdisf="optimized-c"
  cargo:rerun-if-changed=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/x86_64/floatdixf.c
  cargo:rustc-cfg=__floatdixf="optimized-c"
  cargo:rerun-if-changed=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/int_util.c
  cargo:rustc-cfg=__int_util="optimized-c"
  cargo:rerun-if-changed=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/muldc3.c
  cargo:rustc-cfg=__muldc3="optimized-c"
  cargo:rerun-if-changed=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/mulsc3.c
  cargo:rustc-cfg=__mulsc3="optimized-c"
  cargo:rerun-if-changed=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/mulvdi3.c
  cargo:rustc-cfg=__mulvdi3="optimized-c"
  cargo:rerun-if-changed=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/mulvsi3.c
  cargo:rustc-cfg=__mulvsi3="optimized-c"
  cargo:rerun-if-changed=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/mulvti3.c
  cargo:rustc-cfg=__mulvti3="optimized-c"
  cargo:rerun-if-changed=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/mulxc3.c
  cargo:rustc-cfg=__mulxc3="optimized-c"
  cargo:rerun-if-changed=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/negdf2.c
  cargo:rustc-cfg=__negdf2="optimized-c"
  cargo:rerun-if-changed=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/negdi2.c
  cargo:rustc-cfg=__negdi2="optimized-c"
  cargo:rerun-if-changed=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/negsf2.c
  cargo:rustc-cfg=__negsf2="optimized-c"
  cargo:rerun-if-changed=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/negti2.c
  cargo:rustc-cfg=__negti2="optimized-c"
  cargo:rerun-if-changed=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/negvdi2.c
  cargo:rustc-cfg=__negvdi2="optimized-c"
  cargo:rerun-if-changed=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/negvsi2.c
  cargo:rustc-cfg=__negvsi2="optimized-c"
  cargo:rerun-if-changed=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/negvti2.c
  cargo:rustc-cfg=__negvti2="optimized-c"
  cargo:rerun-if-changed=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/paritydi2.c
  cargo:rustc-cfg=__paritydi2="optimized-c"
  cargo:rerun-if-changed=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/paritysi2.c
  cargo:rustc-cfg=__paritysi2="optimized-c"
  cargo:rerun-if-changed=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/parityti2.c
  cargo:rustc-cfg=__parityti2="optimized-c"
  cargo:rerun-if-changed=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/popcountdi2.c
  cargo:rustc-cfg=__popcountdi2="optimized-c"
  cargo:rerun-if-changed=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/popcountsi2.c
  cargo:rustc-cfg=__popcountsi2="optimized-c"
  cargo:rerun-if-changed=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/popcountti2.c
  cargo:rustc-cfg=__popcountti2="optimized-c"
  cargo:rerun-if-changed=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/powixf2.c
  cargo:rustc-cfg=__powixf2="optimized-c"
  cargo:rerun-if-changed=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/subvdi3.c
  cargo:rustc-cfg=__subvdi3="optimized-c"
  cargo:rerun-if-changed=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/subvsi3.c
  cargo:rustc-cfg=__subvsi3="optimized-c"
  cargo:rerun-if-changed=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/subvti3.c
  cargo:rustc-cfg=__subvti3="optimized-c"
  cargo:rerun-if-changed=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/truncdfhf2.c
  cargo:rustc-cfg=__truncdfhf2="optimized-c"
  cargo:rerun-if-changed=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/truncdfsf2.c
  cargo:rustc-cfg=__truncdfsf2="optimized-c"
  cargo:rerun-if-changed=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/truncsfhf2.c
  cargo:rustc-cfg=__truncsfhf2="optimized-c"
  cargo:rerun-if-changed=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/ucmpdi2.c
  cargo:rustc-cfg=__ucmpdi2="optimized-c"
  cargo:rerun-if-changed=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/ucmpti2.c
  cargo:rustc-cfg=__ucmpti2="optimized-c"
  cargo:rerun-if-changed=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/apple_versioning.c
  cargo:rustc-cfg=apple_versioning="optimized-c"
  TARGET = Some("x86_64-pc-windows-msvc")
  OPT_LEVEL = Some("3")
  HOST = Some("x86_64-unknown-linux-gnu")
  CC_x86_64-pc-windows-msvc = None
  CC_x86_64_pc_windows_msvc = None
  TARGET_CC = None
  CC = None
  CROSS_COMPILE = None
  CFLAGS_x86_64-pc-windows-msvc = None
  CFLAGS_x86_64_pc_windows_msvc = None
  TARGET_CFLAGS = None
  CFLAGS = None
  CRATE_CC_NO_DEFAULTS = None
  DEBUG = Some("false")
  CARGO_CFG_TARGET_FEATURE = Some("crt-static,fxsr,mmx,sse,sse2")
  CC_x86_64-pc-windows-msvc = None
  CC_x86_64_pc_windows_msvc = None
  TARGET_CC = None
  CC = None
  CROSS_COMPILE = None
  CFLAGS_x86_64-pc-windows-msvc = None
  CFLAGS_x86_64_pc_windows_msvc = None
  TARGET_CFLAGS = None
  CFLAGS = None
  CRATE_CC_NO_DEFAULTS = None
  CARGO_CFG_TARGET_FEATURE = Some("crt-static,fxsr,mmx,sse,sse2")
  running: "cc" "-O3" "-ffunction-sections" "-fdata-sections" "-m64" "-static" "/Zl" "-ffile-prefix-map=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt=." "-D__func__=__FUNCTION__" "-Fo/home/pnkfelix/Dev/Mozilla/rust-xplat/objdir/build/x86_64-unknown-linux-gnu/stage1-std/x86_64-pc-windows-msvc/release/build/compiler_builtins-53591ff0903ba093/out/absvdi2.o" "-c" "/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/absvdi2.c"
  cargo:warning=cc: error: /Zl: No such file or directory
  exit code: 1

  --- stderr


  error occurred: Command "cc" "-O3" "-ffunction-sections" "-fdata-sections" "-m64" "-static" "/Zl" "-ffile-prefix-map=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt=." "-D__func__=__FUNCTION__" "-Fo/home/pnkfelix/Dev/Mozilla/rust-xplat/objdir/build/x86_64-unknown-linux-gnu/stage1-std/x86_64-pc-windows-msvc/release/build/compiler_builtins-53591ff0903ba093/out/absvdi2.o" "-c" "/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/absvdi2.c" with args "cc" did not execute successfully (status code exit code: 1).


warning: build failed, waiting for other jobs to finish...
error: build failed
command did not execute successfully: "/home/pnkfelix/Dev/Mozilla/rust-xplat/objdir/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "build" "--target" "x86_64-pc-windows-msvc" "-Zbinary-dep-depinfo" "-j" "128" "--release" "--features" "panic-unwind backtrace compiler-builtins-c" "--manifest-path" "/home/pnkfelix/Dev/Mozilla/rust-xplat/library/test/Cargo.toml" "--message-format" "json-render-diagnostics"
expected success, got: exit code: 101
failed to run: /home/pnkfelix/Dev/Mozilla/rust-xplat/objdir/build/bootstrap/debug/bootstrap build --stage 1
Build completed unsuccessfully in 0:00:10

real	0m10.967s
user	0m15.619s
sys	0m0.656s

</details>

created time in 7 days

issue commentrust-lang/rust

LTO triggers apparent miscompilation on Windows 10 x64

At the same time, I'm not really a big fan of putting in such narrowly targetted hacks to work around LLVM bugs, especially ones that have been confirmed to be bugs on LLVM's end.

(having said that, this bug does seem to serve as evidence that our code is probably executing an overflowing addition via unchecked_add. Even though that "merely" generates poison under this particular codegen path (that should be unused and thus won't cause UB), strictly speaking, it is a violation of the contract written for Rust's unchecked_add:

Returns the result of an unchecked addition, resulting in undefined behavior when x + y > T::MAX or x + y < T::MIN.

I'm going to go in and confirm that this add may indeed be overflowing, and if it is, I probably will push for changing to wrapping_add here instead.

AlyoshaVasilieva

comment created time in 7 days

issue commentrust-lang/rust

LTO triggers apparent miscompilation on Windows 10 x64

To be clear: my thinking is that we could change the range.rs and/or Step code to use wrapping_add rather than unchecked_add.

That way, we shouldn't generate any overflow checking code, so I wouldn't expect any significant performance hit.

At the same time, I'm not really a big fan of putting in such narrowly targetted hacks to work around LLVM bugs, especially ones that have been confirmed to be bugs on LLVM's end.

AlyoshaVasilieva

comment created time in 7 days

issue commentrust-lang/rust

LTO triggers apparent miscompilation on Windows 10 x64

The only remaining question on our end is if we should, for the short term, change that range.rs code to not used an unchecked_add, in order to (hopefully) bypass the misoptimization here.

(That, or try to figure out a patch to LLVM to fix the bug on their end.)

AlyoshaVasilieva

comment created time in 10 days

issue commentrust-lang/rust

LTO triggers apparent miscompilation on Windows 10 x64

Filed https://bugs.llvm.org/show_bug.cgi?id=46943 with LLVM upstream.

AlyoshaVasilieva

comment created time in 10 days

push eventpnkfelix/blog.rust-lang.org

Felix S Klock II

commit sha 15c0d9fffa82706ed31d89764559d0e69124ef65

Update 2020-07-31-upcoming-compiler-design-meeting.md

view details

push time in 10 days

PR opened rust-lang/blog.rust-lang.org

Create 2020-07-31-upcoming-compiler-design-meeting.md

Followed structure suggested by https://forge.rust-lang.org/compiler/steering-meeting/how-to-run-planning.html#publish-a-blog-post ; got file name format by looking at past posts.

+28 -0

0 comment

1 changed file

pr created time in 10 days

push eventpnkfelix/blog.rust-lang.org

Felix S Klock II

commit sha da774a9b76011429c89bd2666acb6099fa9a8bff

Create 2020-07-31-upcoming-compiler-design-meeting.md

view details

push time in 10 days

issue commentrust-lang/compiler-team

Discuss results of 2020 Contributor Survey

discussed in today's planning meeting; scheduled for August 14th meeting slot.

<a target="_blank" href="https://calendar.google.com/event?action=TEMPLATE&tmeid=Mzh2ZWlmNjlnbnBtM212OTI0dXN2aWNodG8gNnU1cnJ0Y2U2bHJ0djA3cGZpM2RhbWdqdXNAZw&tmsrc=6u5rrtce6lrtv07pfi3damgjus%40group.calendar.google.com"></a>

mark-i-m

comment created time in 10 days

issue commentrust-lang/rust

error: could not compile `gkrust` since Rust 1.43 on SPARC Solaris

self-assigning to investigate whether its reasonable to replicate this atop GCC build farm or not

psumbera

comment created time in 11 days

issue commentrust-lang/rust

Compiler doesn't terminate with --release

self-assigning to 1. verify this is an LLVM bug and if so, 2. isolate .bc file that we can use to file bug against LLVM itself.

io12

comment created time in 11 days

issue commentrust-lang/rust

Compiler doesn't terminate with --release

@rustbot ping llvm

io12

comment created time in 11 days

pull request commentrust-lang/rust

[stable] 1.45.2 release

@bors r+

Mark-Simulacrum

comment created time in 11 days

issue commentrust-lang/rust

Regression from 1.44 to 1.45

@lcnr commented:

This is a duplicate of the already fixed #73609

by the way, this issue was not, technically, a duplicate of #73609.

Or at least, the issue described in #73609 only surfaces under conditions witnessed after commit 38bd83df88288f2f8d1fc2dd317189cac3825920

<details> <summary>bisected with <a href='https://github.com/rust-lang/cargo-bisect-rustc'>cargo-bisect-rustc</a> v0.5.2</summary>

Host triple: x86_64-unknown-linux-gnu Reproduce with:

cargo bisect-rustc 2020-04-01 --end 2020-06-22 -- run

</details>

while this issue surfaces under conditions witnessed after commit 3fe4dd2dda2826643c4ce4ee7307707a90e08d25

<details> <summary>bisected with <a href='https://github.com/rust-lang/cargo-bisect-rustc'>cargo-bisect-rustc</a> v0.5.2</summary>

Host triple: x86_64-unknown-linux-gnu Reproduce with:

cargo bisect-rustc 2020-05-01 --end 2020-06-01 -- run

</details>

It does seem like the same patch fixes both issues; i.e., it seems likely that there is indeed one bug underlying both distinct issues.

But the fact that they are distinct issues helps explain why we did not backport the fix to beta way back when.

mcarton

comment created time in 11 days

pull request commentrust-lang/rust

Fix #[track_caller] shims for trait objects.

discussed stable nomination in T-compiler meeting.

@rustbot modify labels: stable-accepted

anp

comment created time in 12 days

pull request commentrust-lang/rust

Fix incorrect clashing_extern_declarations warnings.

discussed at T-compiler meeting.

We decided the complexity of this PR, weighed against the bug it fixes, does not warrant a backport.

However, we agreed that a PR that just changed the lint on beta to be allow-by-default would be a reasonable thing to put on the beta branch.

jumbatm

comment created time in 12 days

pull request commentrust-lang/rust

Fix incorrect clashing_extern_declarations warnings.

@rustbot modify labels: -beta-nominated

jumbatm

comment created time in 12 days

pull request commentrust-lang/rust

Fix #[track_caller] shims for trait objects.

discussed in T-compiler meeting.

@rustbot modify labels: beta-accepted

anp

comment created time in 12 days

pull request commentrust-lang/rust

rustc_target: Add a target spec option for disabling `--eh-frame-hdr`

discussed in T-compiler meeting.

@rustbot modify labels: beta-accepted

petrochenkov

comment created time in 12 days

pull request commentrust-lang/rust

Add the aarch64-apple-darwin target

discussed in T-compiler meeting. beta-accepted.

shepmaster

comment created time in 12 days

issue commentrust-lang/rust

Lifetime error when indexing with borrowed index in beta but not in stable

assigning to @nikomatsakis but they will probably need to delegate as there time is limited in near future.

rodrimati1992

comment created time in 12 days

issue commentrust-lang/rust

Unexpected trait resolution overflow error

self-assigning to assist with, at least, getting an MCVE. (See also my blog post on creating MCVEs: http://blog.pnkfx.org/blog/2019/11/18/rust-bug-minimization-patterns/ )

weiznich

comment created time in 12 days

pull request commentrust-lang/rust

The const propagator cannot trace references.

discussed at T-compiler meeting; stable-accepted

oli-obk

comment created time in 12 days

issue commentrust-lang/rust

LLVM error: "Instruction does not dominate all uses!" on Windows

I've narrowed the rust-template crate itself down to this pair of files: a main.rs and a Cargo.toml that specifies the precise version of tokio one needs to use to replicate the problem:

// src/main.rs
use tokio;
use std::error::Error;
use std::sync::Mutex;

#[allow(dead_code)]
enum Msg {
    A(Vec<()>),
    B,
}

#[allow(unused_must_use)]
#[tokio::main]
async fn main() -> Result<(), Box<dyn Error>> {
    let (_, mut rx) = tokio::sync::mpsc::unbounded_channel::<Msg>();
    let entity = Box::new(Mutex::new(()));

    tokio::spawn(async move {
        tokio::select! {
            Some(msg) = rx.recv() => {
                entity.lock();
                drop(msg);
            }
        }
        entity.lock();
    });

    return Ok(());
}
# Cargo.toml
[package]
name = "rust-template"
version = "0.1.0"
authors = ["linyongxing <xtutu0202@gmail.com>"]
edition = "2018"
# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

default-run = "rust-template"

[dependencies]
tokio = { version = "=0.2.21", features = ["rt-core", "macros", "sync"] }

With these two files in a fresh crate, I get this from a release build:

cargo build --release
    Updating crates.io index
   Compiling proc-macro2 v1.0.19
   Compiling unicode-xid v0.2.1
   Compiling syn v1.0.36
   Compiling bytes v0.5.6
   Compiling fnv v1.0.7
   Compiling pin-project-lite v0.1.7
   Compiling quote v1.0.7
   Compiling tokio-macros v0.2.5
   Compiling tokio v0.2.21
   Compiling rust-template v0.1.0 (C:\Users\pfxbo\temp-rust-debug\rust-template)
Instruction does not dominate all uses!
  %182 = phi i8* [ %92, %91 ], [ %55, %190 ], [ %182, %89 ], [ %182, %85 ], [ %182, %187 ], [ %182, %112 ], [ %182, %108 ], [ %182, %105 ], [ %182, %101 ]
  %182 = phi i8* [ %92, %91 ], [ %55, %190 ], [ %182, %89 ], [ %182, %85 ], [ %182, %187 ], [ %182, %112 ], [ %182, %108 ], [ %182, %105 ], [ %182, %101 ]
Instruction does not dominate all uses!
  %182 = phi i8* [ %92, %91 ], [ %55, %190 ], [ %182, %89 ], [ %182, %85 ], [ %182, %187 ], [ %182, %112 ], [ %182, %108 ], [ %182, %105 ], [ %182, %101 ]
  %182 = phi i8* [ %92, %91 ], [ %55, %190 ], [ %182, %89 ], [ %182, %85 ], [ %182, %187 ], [ %182, %112 ], [ %182, %108 ], [ %182, %105 ], [ %182, %101 ]
Instruction does not dominate all uses!
  %182 = phi i8* [ %92, %91 ], [ %55, %190 ], [ %182, %89 ], [ %182, %85 ], [ %182, %187 ], [ %182, %112 ], [ %182, %108 ], [ %182, %105 ], [ %182, %101 ]
  %182 = phi i8* [ %92, %91 ], [ %55, %190 ], [ %182, %89 ], [ %182, %85 ], [ %182, %187 ], [ %182, %112 ], [ %182, %108 ], [ %182, %105 ], [ %182, %101 ]
Instruction does not dominate all uses!
  %182 = phi i8* [ %92, %91 ], [ %55, %190 ], [ %182, %89 ], [ %182, %85 ], [ %182, %187 ], [ %182, %112 ], [ %182, %108 ], [ %182, %105 ], [ %182, %101 ]
  %182 = phi i8* [ %92, %91 ], [ %55, %190 ], [ %182, %89 ], [ %182, %85 ], [ %182, %187 ], [ %182, %112 ], [ %182, %108 ], [ %182, %105 ], [ %182, %101 ]
Instruction does not dominate all uses!
  %182 = phi i8* [ %92, %91 ], [ %55, %190 ], [ %182, %89 ], [ %182, %85 ], [ %182, %187 ], [ %182, %112 ], [ %182, %108 ], [ %182, %105 ], [ %182, %101 ]
  %182 = phi i8* [ %92, %91 ], [ %55, %190 ], [ %182, %89 ], [ %182, %85 ], [ %182, %187 ], [ %182, %112 ], [ %182, %108 ], [ %182, %105 ], [ %182, %101 ]
Instruction does not dominate all uses!
  %182 = phi i8* [ %92, %91 ], [ %55, %190 ], [ %182, %89 ], [ %182, %85 ], [ %182, %187 ], [ %182, %112 ], [ %182, %108 ], [ %182, %105 ], [ %182, %101 ]
  %182 = phi i8* [ %92, %91 ], [ %55, %190 ], [ %182, %89 ], [ %182, %85 ], [ %182, %187 ], [ %182, %112 ], [ %182, %108 ], [ %182, %105 ], [ %182, %101 ]
Instruction does not dominate all uses!
  %182 = phi i8* [ %92, %91 ], [ %55, %190 ], [ %182, %89 ], [ %182, %85 ], [ %182, %187 ], [ %182, %112 ], [ %182, %108 ], [ %182, %105 ], [ %182, %101 ]
  %182 = phi i8* [ %92, %91 ], [ %55, %190 ], [ %182, %89 ], [ %182, %85 ], [ %182, %187 ], [ %182, %112 ], [ %182, %108 ], [ %182, %105 ], [ %182, %101 ]
in function _ZN97_$LT$core..future..from_generator..GenFuture$LT$T$GT$$u20$as$u20$core..future..future..Future$GT$4poll17h257417a290b49d85E
LLVM ERROR: Broken function found, compilation aborted!
error: could not compile `rust-template`.

To learn more, run the command again with --verbose.
kryptan

comment created time in 13 days

issue commentrust-lang/rust

LTO triggers apparent miscompilation on Windows 10 x64

thank you for that excellent analysis @luqmana

AlyoshaVasilieva

comment created time in 15 days

issue commentrust-lang/rust

LLVM error: "Instruction does not dominate all uses!" on Windows

Thanks @xtutu ! I was able to replicate the LLVM assertion now with that Cargo.lock in place! (And of course, I had to remember to do cargo build --release instead of a debug build. 😉 )

kryptan

comment created time in 15 days

issue commentrust-lang/rust

LTO triggers apparent miscompilation on Windows 10 x64

> $Env:RUSTFLAGS="-C llvm-args=-cvp-dont-add-nowrap-flags"
> cargo run --release
   Compiling bmp-minimal v0.1.0 (C:\X\bmp-minimal)
    Finished release [optimized] target(s) in 2.39s
     Running `target\release\bmp-minimal.exe`
memory allocation of 13421772800 bytes failederror: process didn't exit successfully: `target\release\bmp-minimal.exe` (exit code: 0xc0000409, STATUS_STACK_BUFFER_OVERRUN)
> rustc --version
rustc 1.45.0 (5c1f21c3b 2020-07-13)

Still fails on my end, unless I'm doing something wrong.

I'm no windows expert, but you might be doing something wrong...

Or at least, here is my local transcript:

c:\Users\pfxbo\issue_74498>set RUSTFLAGS=
set RUSTFLAGS=

c:\Users\pfxbo\issue_74498>echo %RUSTFLAGS%
echo %RUSTFLAGS%
%RUSTFLAGS%

c:\Users\pfxbo\issue_74498>cargo run --release
cargo run --release
   Compiling issue_74498 v0.1.0 (C:\Users\pfxbo\issue_74498)
    Finished release [optimized] target(s) in 2.25s
     Running `target\release\issue_74498.exe`
memory allocation of 53687091200 bytes failederror: process didn't exit successfully: `target\release\issue_74498.exe` (exit code: 0xc0000409, STATUS_STACK_BUFFER_OVERRUN)

c:\Users\pfxbo\issue_74498>set RUSTFLAGS=-Cllvm-args=-cvp-dont-add-nowrap-flags
set RUSTFLAGS=-Cllvm-args=-cvp-dont-add-nowrap-flags

c:\Users\pfxbo\issue_74498>echo %RUSTFLAGS%
echo %RUSTFLAGS%
-Cllvm-args=-cvp-dont-add-nowrap-flags

c:\Users\pfxbo\issue_74498>cargo run --release
cargo run --release
   Compiling issue_74498 v0.1.0 (C:\Users\pfxbo\issue_74498)
    Finished release [optimized] target(s) in 2.18s
     Running `target\release\issue_74498.exe`
1025 bytes written

c:\Users\pfxbo\issue_74498>cargo --version
cargo --version
cargo 1.44.1 (88ba85757 2020-06-11)

c:\Users\pfxbo\issue_74498>rustc --version
rustc --version
rustc 1.44.1 (c7087fe00 2020-06-17)

c:\Users\pfxbo\issue_74498>

Having said that, I did see some evidence in some other runs that maybe setting this flag doesn't resolve the issue in all cases. I haven't gotten to the bottom of those observations yet; I just wanted to note that I had observed some sensitivity to the flag.

AlyoshaVasilieva

comment created time in 17 days

PR opened rust-lang/compiler-team

Escew links to root page of forge.rlo

Fix #334.

The steering-meeting changes are, I think, obviously better.

The only change I"m not sure about is the change so that "Compiler team procedures" links to the specific compiler page on forge. The main problem I have with that is that page itself does not actually document any procedures, nor even link to subpages with such documentation.

  • However, I justify this change by saying that I think in an ideal world, each main page would have links to each of its subpages, because often the titles alone in the Table-of-Contents on the left-hand side are not really enough for a reader who arrives on the forge without any experience or context for what they are looking for.
+3 -3

0 comment

3 changed files

pr created time in 18 days

create barnchpnkfelix/compiler-team

branch : eschew-links-to-forge-root

created branch time in 18 days

PR opened rust-lang/rust-forge

link to proposals page from main steering-meeting page

link to proposals page so that the main steering-meeting page has "everything" in one place.

(The motivation for this is to provide a usable target page for other pages outside forge, such as the compiler-team site, that want to explain the steering meeting.)

+5 -0

0 comment

1 changed file

pr created time in 18 days

fork pnkfelix/rust-forge

Information useful to people contributing to Rust

https://forge.rust-lang.org/

fork in 18 days

issue commentrust-lang/rust

LLVM error: "Instruction does not dominate all uses!" on Windows

@xtutu I tried to reproduce the problem in a Windows VM with your temp-rust-debug repository, but I was not able to do so at the commits you highlighted.

There's one more factor I haven't accounted for: Changes to crate dependencies. Can you check-in a Cargo.lock file into temp-rust-debug, one that shows the problem atop 3e9935f4d1b361ac557?

kryptan

comment created time in 18 days

pull request commentrust-lang/rust

delay_span_bug instead of silent ignore

@bors r+ rollup=true

Mark-Simulacrum

comment created time in 18 days

pull request commentrust-lang/rust

Fix an ICE on an invalid `binding @ ...` in a tuple struct pattern

The beta nomination was discussed at weekly T-compiler meeting.

The stable nomination was also discussed at that same meeting.

At the end of both discussions, I noted (and @Mark-Simulacrum agreed) that we'd be more comfortable backporting this if it guarded against the scenario where this guard fires but the AST-lowering code, for whatever reason, doesn't signal an error.

In particular, we think that should be implementable via a delay_span_bug invocation.

Having said that, adding a delay_span_bug invocation is not a strict prerequisite for the backport; it is merely something we see as a "nice to have" since it would give us confidence that this change cannot cause a miscompilation down the road.

Having said that: beta backport approved, and stable backport approved.

jakubadamw

comment created time in 19 days

pull request commentrust-lang/rust

Use `ReEmpty(U0)` as the implicit region bound in typeck

the stable-nomination was also discussed (separately) at the weekly T-compiler triage meeting.

We are a little nervous that this only landed so recently, and yet we have a (stable) point release expected next week.

Still, this is pretty low risk, we think. We will keep our eye out collectively for suspicious behavior on nightly, and revert (at least from stable) if we see anything fishy.

stable-accepted.

matthewjasper

comment created time in 19 days

pull request commentrust-lang/rust

Correctly parse `{} && false` in tail expression

discussed at weekly T-compiler triage meeting.

Declining to backport (for both nominations). Removing nomination labels accordingly.

estebank

comment created time in 19 days

pull request commentrust-lang/rust

Use `ReEmpty(U0)` as the implicit region bound in typeck

discussed at weekly T-compiler triage meeting.

beta-accepted

matthewjasper

comment created time in 19 days

pull request commentrust-lang/rust

improper_ctypes_definitions: allow `Box`

discussed at weekly T-compiler triage meeting.

beta-accepted.

davidtwco

comment created time in 19 days

pull request commentrust-lang/rust

Don't panic if the lhs of a div by zero is not statically known

discussed at weekly T-compiler triage meeting.

beta-accepted.

oli-obk

comment created time in 19 days

issue commentrust-lang/compiler-team

website: fwding addresses to forge should try to link to specific forge pages, and we should internally avoid linking to fwding pages

(normally I'd make a PR to fix the instance of this I noted, but I figured I might have a go at a more general search for other occurrences of the two anti-patterns noted here.)

pnkfelix

comment created time in 19 days

issue openedrust-lang/compiler-team

website: fwding addresses to forge should try to link to specific forge pages, and we should internally avoid linking to forwarding pages

From https://rust-lang.github.io/compiler-team/about/steering-meeting/, I wanted to show someone the process to use to propose a meeting.

The link for the procedure on the aforementioned page was given as: https://rust-lang.github.io/compiler-team/procedures/steering-meeting/

but that page is now just:

This content has moved to the <a href=https://forge.rust-lang.org/>Rust forge</a>.

Which is suboptimal:

  1. Its fine for a forwarding page to exist (due to other pages potentially linking here), but it should link to a more specific page within forge rather than just the main landing page for forge
  2. The original page should not link to the internal forwarding page anymore.

created time in 19 days

pull request commentrust-lang/rust

Serialize span hygiene data

anyway I think I'd be okay with r+'ing this PR, once its in a building state according to the CI.

I would definitely want to avoid including it in a rollup, though.

@bors rollup=never

Aaron1011

comment created time in 24 days

pull request commentrust-lang/rust

Serialize span hygiene data

At this point I don't have any useful feedback on the approach used for handling the expn-id's.

(I have a suspicion that this pattern occurs elsewhere in the compiler, in other spots where we need to remap data that has been serialized in some fashion to the local executing context, but I wasn't able to find a proper match with a quick search, so I'm leaving that as a random musing for now.)

I think I understand @petrochenkov 's concern about stable-hashing, except for one detail: I don't think that ExpnId even implements HashStable ... ; SyntaxContext does implement it, yes, but I think that implementation is careful to avoid the problem @petrochenkov describes.

  • Am I wrong here? Does ExpnId indirectly implement HashStable somehow?
Aaron1011

comment created time in 24 days

Pull request review commentrust-lang/rust

Serialize span hygiene data

 impl DesugaringKind {     } } -impl Encodable for ExpnId {-    fn encode<E: Encoder>(&self, _: &mut E) -> Result<(), E::Error> {-        Ok(()) // FIXME(jseyfried) intercrate hygiene+impl UseSpecializedEncodable for ExpnId {}+impl UseSpecializedDecodable for ExpnId {}++/// Additional information used to assist in decoding hygiene data+pub struct HygieneContext {+    // Maps serialized `SyntaxContext` ids to a `SyntaxContext` in the current+    // global `HygieneData`. When we deserialize a `SyntaxContext`, we need to create+    // a new id in the global `HygieneData`. This map tracks the ID we end up picking,+    // so that multiple occurences of the same serialized id are decoded to the same+    // `SyntaxContext`+    remapped_ctxts: Lock<Vec<Option<SyntaxContext>>>,+    // The same as `remapepd_ctxts`, but for `ExpnId`s+    remapped_expns: Lock<Vec<Option<ExpnId>>>,+}++impl HygieneContext {+    pub fn new() -> HygieneContext {+        HygieneContext {+            remapped_ctxts: Lock::new(Vec::new()),+            remapped_expns: Lock::new(Vec::new()),+        }     } } -impl Decodable for ExpnId {-    fn decode<D: Decoder>(_: &mut D) -> Result<Self, D::Error> {-        Ok(ExpnId::root()) // FIXME(jseyfried) intercrate hygiene+pub fn decode_expn_id<+    'a,+    D: Decoder,+    F: FnOnce(&mut D, u32) -> Result<ExpnData, D::Error>,+    G: FnOnce(CrateNum) -> &'a HygieneContext,+>(+    d: &mut D,+    mode: ExpnDataDecodeMode<'a, G>,+    decode_data: F,+) -> Result<ExpnId, D::Error> {+    let index = u32::decode(d)?;+    let context = match mode {+        ExpnDataDecodeMode::IncrComp(context) => context,+        ExpnDataDecodeMode::Metadata(get_context) => {+            let krate = CrateNum::decode(d)?;+            get_context(krate)+        }+    };++    // Do this after decoding, so that we decode a `CrateNum`+    // if necessary+    if index == ExpnId::root().as_u32() {+        debug!("decode_expn_id: deserialized root");+        return Ok(ExpnId::root());+    }++    let outer_expns = &context.remapped_expns;++    // Ensure that the lock() temporary is dropped early

I still think that if you want to make things explicit with braces,, then it should be braces that have an effect.

Putting braces in like this may lead people reading the code to think erroneously that these braces are necessary to encode the dynamic extent you desire here. I would prefer to avoid fueling such misunderstanding.

But given that the project does not have official guidance as to coding style in cases like this, I will not block landing the PR based on this disagreement.

Aaron1011

comment created time in 24 days

pull request commentrust-lang/rust

Stop processing unreachable blocks when solving dataflow

@bors r+ rollup=true

ecstatic-morse

comment created time in 24 days

Pull request review commentrust-lang/rust

Don't run `everybody_loops` for rustdoc; instead ignore resolution errors

 fn configure_and_expand_inner<'a>(         )     }); -    // If we're actually rustdoc then there's no need to actually compile-    // anything, so switch everything to just looping-    let mut should_loop = sess.opts.actually_rustdoc;     if let Some(PpMode::PpmSource(PpSourceMode::PpmEveryBodyLoops)) = sess.opts.pretty {-        should_loop |= true;-    }-    if should_loop {         log::debug!("replacing bodies with loop {{}}");         util::ReplaceBodyWithLoop::new(&mut resolver).visit_crate(&mut krate);     }

I wrote a blog post in late 2019 that demonstrated use of everybody_loops. So yes, I do still use it.

http://blog.pnkfx.org/blog/2019/11/18/rust-bug-minimization-patterns/#L..loopification.....via.pretty-printer

jyn514

comment created time in 25 days

create barnchpnkfelix/rustc-guide

branch : discard-discord

created branch time in a month

pull request commentrust-lang/rust

[WIP] Upgrade to LLVM 11

Discussed at T-compiler meeting.

After some debate about the tradeoffs here, there was general agreement that we should probably land this LLVM 11 upgrade in nightly, with a plan to beta-backport the final LLVM 11 release when it comes out.

In particular, this comment was a good summary:

it seems bad to wait another 2ish months for these performance wins without excellent reason, so I'm personally in favor of landing now. I think I've convinced myself that matching LLVM releases is fine to do "in stable" but not really as needed in nightly.

removing nomination label.

cuviper

comment created time in a month

pull request commentrust-lang/rust

mv std libs to std/

discussed at T-compiler meeting. Everyone present was generally in favor of the change as described.

We also decided that this is pretty much the definition of an implementation detail (as opposed to a public facing API issue), which is why it was on T-compiler's docket in the first place. Removing nomination label.

mark-i-m

comment created time in a month

pull request commentrust-lang/rust

Polymorphization

Discussed at T-compiler meeting.

We want to generally move forward with landing this, probably on by default.

Changes like this would normally require a Major Change Proposal (MCP), but we are grandfathering this PR because its development predated the MCP process, and the compiler team knew about its development as it was being made. Plus, it has a thesis associated with it. :wink:

davidtwco

comment created time in a month

pull request commentrust-lang/rust

lint: use `transparent_newtype_field` to avoid ICE

beta-accepted

Discussion at: https://zulip-archive.rust-lang.org/238009tcompilermeetings/14860weeklymeeting2020071654818.html#204089513

davidtwco

comment created time in a month

issue commentrust-lang/rust

Nightly ICEs trying to normalize during a cast

however, I also think the bug is under control now that the PR has landed on nightly. Reprioritizing as P-high.

BlackHoleFox

comment created time in a month

IssuesEvent

issue commentrust-lang/rust

Nightly ICEs trying to normalize during a cast

reopening; the next beta was cut before this landed in master, so this ended up being a regression-from-stable-to-beta

BlackHoleFox

comment created time in a month

push eventpnkfelix/presentations

dependabot[bot]

commit sha bd5c7ad92ea7aa15fcfb01552f0eaa5bf6d763d1

Bump mustache from 0.7.3 to 4.0.1 in /qcon-london2016-deploy Bumps [mustache](https://github.com/janl/mustache.js) from 0.7.3 to 4.0.1. - [Release notes](https://github.com/janl/mustache.js/releases) - [Changelog](https://github.com/janl/mustache.js/blob/master/CHANGELOG.md) - [Commits](https://github.com/janl/mustache.js/compare/0.7.3...v4.0.1) Signed-off-by: dependabot[bot] <support@github.com>

view details

Felix S Klock II

commit sha fc9bdf4981871efcee7228d3ec7cfca2b6475282

Merge pull request #1 from pnkfelix/dependabot/npm_and_yarn/qcon-london2016-deploy/mustache-4.0.1 Bump mustache from 0.7.3 to 4.0.1 in /qcon-london2016-deploy

view details

push time in a month

PR merged pnkfelix/presentations

Bump mustache from 0.7.3 to 4.0.1 in /qcon-london2016-deploy dependencies

Bumps mustache from 0.7.3 to 4.0.1. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/janl/mustache.js/releases">mustache's releases</a>.</em></p> <blockquote> <h2>v3.1.0</h2> <h3>Added</h3> <ul> <li><a href="https://github-redirect.dependabot.com/janl/mustache.js/issues/717">#717</a>: Added support .js files as views in command line tool, by [<a href="https://github.com/JEStaubach">@JEStaubach</a>].</li> </ul> <h3>Fixed</h3> <ul> <li><a href="https://github-redirect.dependabot.com/janl/mustache.js/issues/716">#716</a>: Bugfix for indentation of inline partials, by [<a href="https://github.com/yotammadem">@yotammadem</a>].</li> </ul> <p><a href="https://github-redirect.dependabot.com/janl/mustache.js/issues/716">#716</a>: <a href="https://github-redirect.dependabot.com/janl/mustache.js/issues/716">janl/mustache.js#716</a> <a href="https://github-redirect.dependabot.com/janl/mustache.js/issues/717">#717</a>: <a href="https://github-redirect.dependabot.com/janl/mustache.js/issues/717">janl/mustache.js#717</a> [<a href="https://github.com/JEStaubach">@JEStaubach</a>]: <a href="https://github.com/JEStaubach">https://github.com/JEStaubach</a> [<a href="https://github.com/yotammadem">@yotammadem</a>]: <a href="https://github.com/yotammadem">https://github.com/yotammadem</a></p> <h2>v3.0.2</h2> <h3>Fixed</h3> <ul> <li><a href="https://github-redirect.dependabot.com/janl/mustache.js/issues/705">#705</a>: Fix indentation of partials, by <a href="https://github.com/kevindew">@kevindew</a> and <a href="https://github.com/yotammadem">@yotammadem</a>.</li> </ul> <h3>Dev</h3> <ul> <li><a href="https://github-redirect.dependabot.com/janl/mustache.js/issues/701">#701</a>: Fix test failure for Node 10 and above, by <a href="https://github.com/andersk">@andersk</a>.</li> <li><a href="https://github-redirect.dependabot.com/janl/mustache.js/issues/704">#704</a>: Lint all test files just like the source files, by <a href="https://github.com/phillipj">@phillipj</a>.</li> <li>Start experimenting & comparing GitHub Actions vs Travis CI, by <a href="https://github.com/phillipj">@phillipj</a>.</li> </ul> <h2>v3.0.1</h2> <p><a href="https://github-redirect.dependabot.com/janl/mustache.js/issues/679">#679</a>: Fix partials not rendering tokens when using custom tags, by <a href="https://github.com/stackchain">@stackchain</a>.</p> <h2>v3.0.0</h2> <h2>[3.0.0] / 16 September 2018</h2> <p>We are very happy to announce a new major version of mustache.js. We want to be very careful not to break projects out in the wild, and adhering to <a href="http://semver.org/">Semantic Versioning</a> we have therefore cut this new major version.</p> <p>The changes introduced will likely not require any actions for most using projects. The things to look out for that might cause unexpected rendering results are described in the migration guide below.</p> <p>A big shout out and thanks to [<a href="https://github.com/raymond-lam">@raymond-lam</a>] for this release! Without his contributions with code and issue triaging, this release would never have happened.</p> <h3>Major</h3> <ul> <li><a href="https://github-redirect.dependabot.com/janl/mustache.js/issues/618">#618</a>: Allow rendering properties of primitive types that are not objects, by [<a href="https://github.com/raymond-lam">@raymond-lam</a>].</li> <li><a href="https://github-redirect.dependabot.com/janl/mustache.js/issues/643">#643</a>: <code>Writer.prototype.parse</code> to cache by tags in addition to template string, by [<a href="https://github.com/raymond-lam">@raymond-lam</a>].</li> <li><a href="https://github-redirect.dependabot.com/janl/mustache.js/issues/664">#664</a>: Fix <code>Writer.prototype.parse</code> cache, by [<a href="https://github.com/seminaoki">@seminaoki</a>].</li> </ul> <h3>Minor</h3> <ul> <li><a href="https://github-redirect.dependabot.com/janl/mustache.js/issues/673">#673</a>: Add <code>tags</code> parameter to <code>Mustache.render()</code>, by [<a href="https://github.com/raymond-lam">@raymond-lam</a>].</li> </ul> <!-- raw HTML omitted --> </blockquote> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/janl/mustache.js/blob/master/CHANGELOG.md">mustache's changelog</a>.</em></p> <blockquote> <h2>[4.0.1] / 15 March 2020</h2> <h3>Fixed</h3> <ul> <li><a href="https://github-redirect.dependabot.com/janl/mustache.js/issues/739">#739</a>: Fix custom delimiters in nested partials, by [<a href="https://github.com/aielo">@aielo</a>].</li> </ul> <h2>[4.0.0] / 16 January 2020</h2> <p>Majority of using projects don't have to worry by this being a new major version.</p> <p><strong>TLDR;</strong> if your project manipulates <code>Writer.prototype.parse | Writer.cache</code> directly or uses <code>.to_html()</code>, you probably have to change that code.</p> <p>This release allows the internal template cache to be customised, either by disabling it completely or provide a custom strategy deciding how the cache should behave when mustache.js parses templates.</p> <pre lang="js"><code>const mustache = require('mustache'); <p>// disable caching Mustache.templateCache = undefined;</p> <p>// or use a built-in Map in modern environments Mustache.templateCache = new Map(); </code></pre></p> <p>Projects that wanted to customise the caching behaviour in earlier versions of mustache.js were forced to override internal method responsible for parsing templates; <code>Writer.prototype.parse</code>. In short, that was unfortunate because there is more than caching happening in that method.</p> <p>We've improved that now by introducing a first class API that only affects template caching.</p> <p>The default template cache behaves as before and is still compatible with older JavaScript environments. For those who wants to provide a custom more sopisiticated caching strategy, one can do that with an object that adheres to the following requirements:</p> <pre lang="ts"><code>{ set(cacheKey: string, value: string): void get(cacheKey: string): string | undefined clear(): void } </code></pre> <h3>Added</h3> <ul> <li><a href="https://github-redirect.dependabot.com/janl/mustache.js/issues/731">#731</a>: Allow template caching to be customised, by [<a href="https://github.com/AndrewLeedham">@AndrewLeedham</a>].</li> </ul> <h3>Removed</h3> <ul> <li><a href="https://github-redirect.dependabot.com/janl/mustache.js/issues/735">#735</a>: Remove <code>.to_html()</code>, by [<a href="https://github.com/phillipj">@phillipj</a>].</li> </ul> <!-- raw HTML omitted --> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/janl/mustache.js/commit/1de94bbdd3fe4b903cfbc084ebaaccfd1299dd3f"><code>1de94bb</code></a> :ship: bump to version 4.0.1</li> <li><a href="https://github.com/janl/mustache.js/commit/f3bd88837eda6f08bef5ace4b302f8d0e1cc8e14"><code>f3bd888</code></a> Fix custom delimiters in nested partials (<a href="https://github-redirect.dependabot.com/janl/mustache.js/issues/739">#739</a>)</li> <li><a href="https://github.com/janl/mustache.js/commit/aca97b82c80e8fd1d36162e05e4b289380965d96"><code>aca97b8</code></a> :ship: bump to version 4.0.0</li> <li><a href="https://github.com/janl/mustache.js/commit/f3012a2477a90ac98a1f8cbd2a53bafaeb4adc7d"><code>f3012a2</code></a> Remove mustache.to_html() (<a href="https://github-redirect.dependabot.com/janl/mustache.js/issues/735">#735</a>)</li> <li><a href="https://github.com/janl/mustache.js/commit/5938104ba717a43dfd9e963dd67accdc1a526421"><code>5938104</code></a> Use fetched template in usage example</li> <li><a href="https://github.com/janl/mustache.js/commit/3bdd27c4e762f665232dc46186c7639e60dbd70e"><code>3bdd27c</code></a> Add a section about TypeScript defs in README</li> <li><a href="https://github.com/janl/mustache.js/commit/7f94f138cbec5592529605cc8af02b58ed20c456"><code>7f94f13</code></a> Move CLI and contribute section down in README</li> <li><a href="https://github.com/janl/mustache.js/commit/39ee6ffc2c25ce8f89a906104498450bbfb31527"><code>39ee6ff</code></a> Point out it's a zero-dependency package in README</li> <li><a href="https://github.com/janl/mustache.js/commit/c41045baf8fcb14cc6b48db4b784dcef3e82cd26"><code>c41045b</code></a> Removing the rtype API definitions from README</li> <li><a href="https://github.com/janl/mustache.js/commit/bd742d5080f70008dc35e58a1d87152938d2f98b"><code>bd742d5</code></a> Add response.text() from fetch() in README example</li> <li>Additional commits viewable in <a href="https://github.com/janl/mustache.js/compare/0.7.3...v4.0.1">compare view</a></li> </ul> </details> <details> <summary>Maintainer changes</summary> <p>This version was pushed to npm by <a href="https://www.npmjs.com/~flipp">flipp</a>, a new releaser for mustache since your current version.</p> </details> <br />

Dependabot compatibility score

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


<details> <summary>Dependabot commands and options</summary> <br />

You can trigger Dependabot actions by commenting on this PR:

  • @dependabot rebase will rebase this PR
  • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
  • @dependabot merge will merge this PR after your CI passes on it
  • @dependabot squash and merge will squash and merge this PR after your CI passes on it
  • @dependabot cancel merge will cancel a previously requested merge and block automerging
  • @dependabot reopen will reopen this PR if it is closed
  • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
  • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
  • @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
  • @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
  • @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
  • @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

You can disable automated security fix PRs for this repo from the Security Alerts page.

</details>

+1 -1

0 comment

1 changed file

dependabot[bot]

pr closed time in a month

push eventpnkfelix/presentations

Felix S. Klock II

commit sha d7132cd27658b4d16fbde9b16148669ff3dab575

Add month (July 2020) to the description for the PLDI AMA entry.

view details

push time in a month

push eventpnkfelix/presentations

Felix S. Klock II

commit sha f412ea6bd865e7501f46fd66126919c25a3cd99b

Add link to my AMA session at virtual PLDI 2020.

view details

push time in a month

issue commentrust-lang/rust

Should include crate name in error message for E0391 (and perhaps others)

(I didn't attempt to include a code snippet because I suspect that this particular instance of the problem is arising due to bootstrap build artifacts lying around. If I do happen to make a MCVE, I'll include it. But I assume this problem can be fixed without needing a whole new MCVE, since presumably we already have test cases for E0391.)

See in particular tests like the following in src/test/ui:

rg "on this crate"

associated-consts/issue-24949-assoc-const-static-recursion-impl.stderr
40:   = note: cycle used when running analysis passes on this crate

associated-consts/issue-24949-assoc-const-static-recursion-trait-default.stderr
40:   = note: cycle used when running analysis passes on this crate

associated-consts/issue-24949-assoc-const-static-recursion-trait.stderr
40:   = note: cycle used when running analysis passes on this crate

issues/issue-23302-3.stderr
35:   = note: cycle used when running analysis passes on this crate

However, none of those are actually emitting the exact error I am witnessing, which is precisely "error[E0391]: cycle detected when running analysis passes on this crate"

(that is, I don't see any ui tests checking for "when running analysis passes on this crate")

pnkfelix

comment created time in a month

issue openedrust-lang/rust

Should include crate name in error message for E0391 (and perhaps others)

While doing a bootstrap build of the compiler with some other build artifacts lying around, I saw the following error message (a small snippet from whole output):

[RUSTC-TIMING] cfg_if test:false 0.035
   Compiling lock_api v0.3.4
[RUSTC-TIMING] scopeguard test:false 0.068
   Compiling crossbeam-utils v0.6.5
   Compiling tracing-core v0.1.10
   Compiling log_settings v0.1.2
error[E0391]: cycle detected when running analysis passes on this crate
  |
  = note: ...which again requires running analysis passes on this crate, completing the cycle

error: aborting due to previous error

For more information about this error, try `rustc --explain E0391`.
error[E0391]: cycle detected when running analysis passes on this crate
  |
  = note: ...which again requires running analysis passes on this crate, completing the cycle

[RUSTC-TIMING] lazy_static test:false 0.079
error: aborting due to previous error

It is sub-optimal to say "on this crate" in a diagnostic like this.

Multiple crates can be compiled in parallel, and thus it can be ambiguous which crate a diagnostic like that is associated with.

In general it would be better to extract a crate name, if possible, and include that in the message, rather than using the simpler-but-potentially-ambiguous "on this crate."

created time in a month

issue commentrust-lang/rust

Nightly ICEs trying to normalize during a cast

Keeping at P-critical based on conversation at: https://zulip-archive.rust-lang.org/245100tcompilerwgprioritizationalerts/57076Iprioritize73747NightlyICEstryingtonormalizeduring.html#203858906

BlackHoleFox

comment created time in a month

pull request commentrust-lang/rust

lint: use `transparent_newtype_field` to avoid ICE

@bors r+ rollup=true

davidtwco

comment created time in a month

issue commentrust-lang/rust

Nightly ICEs trying to normalize during a cast

On the plus side, I was able to run cargo-bisect-rustc on @connorskees 's MCVE, and got this result:

searched nightlies: from nightly-2020-06-22 to nightly-2020-07-14 regressed nightly: nightly-2020-06-26 searched commits: from https://github.com/rust-lang/rust/commit/67100f61e62a86f2bf9e38552ee138e231eddc74 to https://github.com/rust-lang/rust/commit/50fc24d8a172a853b5dfe40702d6550e3b8562ba regressed commit: https://github.com/rust-lang/rust/commit/9f3c96b869b48ecd0bb556c6ad9cd603b4dacfb9

<details> <summary>bisected with <a href='https://github.com/rust-lang/cargo-bisect-rustc'>cargo-bisect-rustc</a> v0.5.2</summary>

Host triple: x86_64-unknown-linux-gnu Reproduce with:

cargo bisect-rustc 

</details>

BlackHoleFox

comment created time in a month

issue commentrust-lang/rust

Nightly ICEs trying to normalize during a cast

Also, it looks to me like this MCVE still reproduces on the current nightly. (So something must have been off with my earlier bisection that claimed it was fixed. The original problem has been tricky for me to consistently reproduce.)

BlackHoleFox

comment created time in a month

issue commentrust-lang/rust

Nightly ICEs trying to normalize during a cast

@connorskees 's MCVE shows that this problem is not windows-specific. Updating labels accordingly.

BlackHoleFox

comment created time in a month

pull request commentrust-lang/rust

Avoid "blacklist"

discussed in today's T-compiler meeting. Removing nomination tag.

tamird

comment created time in a month

pull request commentrust-lang/rust

Avoid "whitelist"

discussed in today's T-compiler meeting. Removing nomination tag.

tamird

comment created time in a month

pull request commentrust-lang/rust

rustdoc: Rename invalid_codeblock_attribute lint to be plural

discussed at today's T-compiler meeting.

accepted for beta backport.

ollie27

comment created time in a month

pull request commentrust-lang/rust

Don't run `everybody_loops` for rustdoc; instead ignore resolution errors

@GuillaumeGomez am I right in interpreting your feedback as a :+1: on the two items that are awaiting "needs-decision' from T-rustdoc?

jyn514

comment created time in a month

Pull request review commentrust-lang/rust

Avoid "whitelist"

 impl<'a, 'tcx> SimilarNamesLocalVisitor<'a, 'tcx> { // this list contains lists of names that are allowed to be similar // the assumption is that no name is ever contained in multiple lists. #[rustfmt::skip]-const WHITELIST: &[&[&str]] = &[+const EXEMPTIONS: &[&[&str]] = &[

(such a rename may require some extra line-breaking to placate tidy, but I personally would be okay with that.)

tamird

comment created time in a month

Pull request review commentrust-lang/rust

Avoid "whitelist"

 impl<'a, 'tcx> SimilarNamesLocalVisitor<'a, 'tcx> { // this list contains lists of names that are allowed to be similar // the assumption is that no name is ever contained in multiple lists. #[rustfmt::skip]-const WHITELIST: &[&[&str]] = &[+const EXEMPTIONS: &[&[&str]] = &[

if you renamed this (and the related occurrence of exemptions above) to ALLOWED_TO_BE_SIMILAR (and allowed_to_be_similar) then the code would be more self-documenting.

tamird

comment created time in a month

pull request commentrust-lang/rust

Avoid "whitelist"

(I'm nominating because I want this PR to be discussed in tomorrows meeting; however, my nomination should not be interpreted as blocking the PR. I'm fine with it being r+'ed, assuming team feedback has been incorporated.)

tamird

comment created time in a month

pull request commentrust-lang/rust

Avoid "blacklist"

(I'm nominating because I want this PR to be discussed in tomorrows meeting; however, my nomination should not be interpreted as blocking the PR. I'm fine with it being r+'ed, assuming team feedback has been incorporated.)

tamird

comment created time in a month

pull request commentrust-lang/rust

Reoder order in which MinGW libs are linked to fix recent breakage

@rustbot modify labels: +beta-accepted

mati865

comment created time in a month

Pull request review commentrust-lang/rust

Serialize span hygiene data

 impl DesugaringKind {     } } -impl Encodable for ExpnId {-    fn encode<E: Encoder>(&self, _: &mut E) -> Result<(), E::Error> {-        Ok(()) // FIXME(jseyfried) intercrate hygiene+impl UseSpecializedEncodable for ExpnId {}+impl UseSpecializedDecodable for ExpnId {}++/// Additional information used to assist in decoding hygiene data+pub struct HygieneContext {+    // Maps serialized `SyntaxContext` ids to a `SyntaxContext` in the current+    // global `HygieneData`. When we deserialize a `SyntaxContext`, we need to create+    // a new id in the global `HygieneData`. This map tracks the ID we end up picking,+    // so that multiple occurences of the same serialized id are decoded to the same+    // `SyntaxContext`+    remapped_ctxts: Lock<Vec<Option<SyntaxContext>>>,+    // The same as `remapepd_ctxts`, but for `ExpnId`s+    remapped_expns: Lock<Vec<Option<ExpnId>>>,+}++impl HygieneContext {+    pub fn new() -> HygieneContext {+        HygieneContext {+            remapped_ctxts: Lock::new(Vec::new()),+            remapped_expns: Lock::new(Vec::new()),+        }     } } -impl Decodable for ExpnId {-    fn decode<D: Decoder>(_: &mut D) -> Result<Self, D::Error> {-        Ok(ExpnId::root()) // FIXME(jseyfried) intercrate hygiene+pub fn decode_expn_id<+    'a,+    D: Decoder,+    F: FnOnce(&mut D, u32) -> Result<ExpnData, D::Error>,+    G: FnOnce(CrateNum) -> &'a HygieneContext,+>(+    d: &mut D,+    mode: ExpnDataDecodeMode<'a, G>,+    decode_data: F,+) -> Result<ExpnId, D::Error> {+    let index = u32::decode(d)?;+    let context = match mode {+        ExpnDataDecodeMode::IncrComp(context) => context,+        ExpnDataDecodeMode::Metadata(get_context) => {+            let krate = CrateNum::decode(d)?;+            get_context(krate)+        }+    };++    // Do this after decoding, so that we decode a `CrateNum`+    // if necessary+    if index == ExpnId::root().as_u32() {+        debug!("decode_expn_id: deserialized root");+        return Ok(ExpnId::root());+    }++    let outer_expns = &context.remapped_expns;++    // Ensure that the lock() temporary is dropped early

Oh, here is a playground demo illustrating what I mean when I say that these braces have no effect.

(The demo also points out a potentially surprising difference in the semantics of if vs if let in terms of what the r-value lifetime rules yield, but that is just a side-note; it does not contradict my main point that these braces have no effect.)

Aaron1011

comment created time in a month

Pull request review commentrust-lang/rust

Serialize span hygiene data

 impl DesugaringKind {     } } -impl Encodable for ExpnId {-    fn encode<E: Encoder>(&self, _: &mut E) -> Result<(), E::Error> {-        Ok(()) // FIXME(jseyfried) intercrate hygiene+impl UseSpecializedEncodable for ExpnId {}+impl UseSpecializedDecodable for ExpnId {}++/// Additional information used to assist in decoding hygiene data+pub struct HygieneContext {+    // Maps serialized `SyntaxContext` ids to a `SyntaxContext` in the current+    // global `HygieneData`. When we deserialize a `SyntaxContext`, we need to create+    // a new id in the global `HygieneData`. This map tracks the ID we end up picking,+    // so that multiple occurences of the same serialized id are decoded to the same+    // `SyntaxContext`+    remapped_ctxts: Lock<Vec<Option<SyntaxContext>>>,+    // The same as `remapepd_ctxts`, but for `ExpnId`s+    remapped_expns: Lock<Vec<Option<ExpnId>>>,+}++impl HygieneContext {+    pub fn new() -> HygieneContext {+        HygieneContext {+            remapped_ctxts: Lock::new(Vec::new()),+            remapped_expns: Lock::new(Vec::new()),+        }     } } -impl Decodable for ExpnId {-    fn decode<D: Decoder>(_: &mut D) -> Result<Self, D::Error> {-        Ok(ExpnId::root()) // FIXME(jseyfried) intercrate hygiene+pub fn decode_expn_id<+    'a,+    D: Decoder,+    F: FnOnce(&mut D, u32) -> Result<ExpnData, D::Error>,+    G: FnOnce(CrateNum) -> &'a HygieneContext,+>(+    d: &mut D,+    mode: ExpnDataDecodeMode<'a, G>,+    decode_data: F,+) -> Result<ExpnId, D::Error> {+    let index = u32::decode(d)?;+    let context = match mode {+        ExpnDataDecodeMode::IncrComp(context) => context,+        ExpnDataDecodeMode::Metadata(get_context) => {+            let krate = CrateNum::decode(d)?;+            get_context(krate)+        }+    };++    // Do this after decoding, so that we decode a `CrateNum`+    // if necessary+    if index == ExpnId::root().as_u32() {+        debug!("decode_expn_id: deserialized root");+        return Ok(ExpnId::root());+    }++    let outer_expns = &context.remapped_expns;++    // Ensure that the lock() temporary is dropped early

I believe these braces you have added here have no effect.

The current r-value lifetime rules will cause the lock() temporary to be dropped at the end of the evaluation of the expression; we do not extend it to the end of the containing block (which in this case would be the fn body of decode_expn_id itself).

(The place where you do need such braces is when you let-bind the value, as you do below with let mut expns = outer_expns.lock();.)


I would say that if your goal is to make the dynamic extent of the lock() temporary as clear as possible to future readers of this code, then I would keep the braces but I would also add a let-binding of the temporary, so that the braces are meaningful.

Aaron1011

comment created time in a month

issue commentrust-lang/rust

Nightly ICEs trying to normalize during a cast

searched nightlies: from nightly-2020-06-28 to nightly-2020-06-29 regressed nightly: nightly-2020-06-29 searched commits: from https://github.com/rust-lang/rust/commit/394e1b40d264aa6928811919c1124fa248e7d802 to https://github.com/rust-lang/rust/commit/2f517ce6f28b5d638cce4c1eccdbe63255b11420 regressed commit: https://github.com/rust-lang/rust/commit/25687caa2e4e35b31c29e28998710670e9d54ee9

<details> <summary>bisected with <a href='https://github.com/rust-lang/cargo-bisect-rustc'>cargo-bisect-rustc</a> v0.5.2</summary>

Host triple: x86_64-pc-windows-msvc Reproduce with:

cargo bisect-rustc success --start 2020-06-28 --end 2020-06-29 --access github --preserve

</details>

BlackHoleFox

comment created time in a month

pull request commentrust-lang/rust

Implement `--extern-location`

@spastorino I think that we still need to wait for the end of the final comment period for the MCP before we can say that this is "just" waiting on review.

I switched its state to waiting-on-fcp, in reference to the 10 day final comment period here

jsgf

comment created time in a month

pull request commentrust-lang/rust

Perform obligation deduplication to avoid buggy `ExistentialMismatch`

stable nom was also discussed. Stable backport approved.

estebank

comment created time in a month

pull request commentrust-lang/rust

rustdoc: Fix doc aliases with crate filtering

discussed in T-compiler meeting

Accepted for beta backport.

ollie27

comment created time in a month

pull request commentrust-lang/rust

Perform obligation deduplication to avoid buggy `ExistentialMismatch`

discussed in T-compiler meeting. Approved for beta-backport.

estebank

comment created time in a month

pull request commentrust-lang/rust

Reoder order in which MinGW libs are linked to fix recent breakage

discussed in last week's T-compiler meeting

Approved for beta backport.

mati865

comment created time in a month

issue commentrust-lang/rust

Nightly ICEs trying to normalize during a cast

This ICE went away between nightly-2020-06-28 and nightly-2020-06-29.

Bisecting further now.

BlackHoleFox

comment created time in a month

pull request commentrust-lang/rust

rustc_lexer: Simplify shebang parsing once more

Discussed in T-compiler meeting; beta backport approved.

petrochenkov

comment created time in a month

pull request commentrust-lang/rust

Change how compiler-builtins gets many CGUs

Discussed in last week's T-compiler meeting

We are inclined to backport the earlier version of this PR that doesn't rely on new cargo stuff. See link above for details.

alexcrichton

comment created time in a month

Pull request review commentrust-lang/rust-forge

Priority levels

+# Priority levels++As the compiler team's resources are limited, the prioritization working group's main goal is to identify the most relevant issues to work on, so that the compiler team can focus on what matters the most.++## Words used in this document:++`issue` refers to bugs and feature requests that are nominated for prioritization, by flagging the `I-Prioritize` label as described below.++This document will define what each label means, and what strategy for each label will be used.++## Labels++Labeling an issue as `I-Prioritize` starts the prioritization process, which will end by removing the `I-Prioritize` label and appending one of the 4 labels we will discuss below:++- P-Critical+- P-High+- P-Medium+- P-Low++Each of these labels defines a strategy the team will adopt regarding:++- The amount of focus a given issue will receive+- How members of the community can get involved++## Definitions++### P-Critical++A `P-Critical` issue is a potentially blocker issue.++The Working Group will keep track of the number of such issues open at the same time (which shouldn't be more than 5), and how long such issues remain open.++Examples of things we typically judge to be “critical” bugs:++- Regressions where code that used to compile no longer does++  - Mitigating conditions that may lower priority:+    - If the code should never have compiled in the first place (but if the regression affects a large number of crates, this may indicate that we need a warning period)+    - If the code in question is theoretical and considered unlikely to exist in the wild, or if it only exists in small, unmaintained packages that are not widely used+  - If a regression has been in stable for a release or two (either because we are still awaiting a fix, or because the bug had laid dormant i.e. undetected), we typically lower the priority as well, because by that time, if the users have not raised a ruckus about the regression, that is a sign that it is inherently not a critical issue. Eg: [an issue that would have been P-Critical but ended up being P-High](https://rust-lang.zulipchat.com/#narrow/stream/227806-t-compiler.2Fwg-prioritization/topic/pre-meeting.20triage.202020-04-09.20.2354818)++- Regressions where code still compiles but does something different than it used to do (dynamic semantics have changed)+  - Mitigating conditions that may lower priority:+    - If code uses feature that is explicitly not specified (e.g. `std::vec::Vec` docs state order in which it drops its elements is subject to change)+- Feature-gated features accessible without a feature gate+  - Mitigating conditions that may lower priority:+    - If the pattern is VERY unlikely+- Soundness holes where common code that should not compile actually does

I think miscompilations are covered by the first bullet, "Regressions where code still compiles but does something different than it used to do (dynamic semantics have changed)", ...

... though arguably that is "solely" talking about regressions. It might be better to talk about deviations from the intended semantics (rather than the historical semantics)

o0Ignition0o

comment created time in a month

issue commentrust-lang/rust

LLVM error: "Instruction does not dominate all uses!" on Windows

oddly enough, I have having trouble creating the original bug atop the listed versions of rustc. (So weird!)

In the meantime, while I resolve that oddity: @xtutu , can you post a link to the source for the crate where you are observing this occurrence of the LLVM error here?

kryptan

comment created time in a month

issue commentrust-lang/rust

LLVM error: "Instruction does not dominate all uses!" on Windows

(checking if I can replicate @xtutu 's observations locally now)

kryptan

comment created time in a month

more