https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=1.56.1 2021-08-27T09:50:44+00:00 2021-08-27T09:50:44+00:00 Michael Woerister michaelwoerister@posteo 2021-08-26T10:46:01+00:00 urn:sha1:af1b65cb18d5fa1358d1ae7a8ed3b1f7c635b6b5 2021-08-26T09:14:31+00:00 lcnr rust@lcnr.de 2021-08-02T07:56:05+00:00 urn:sha1:f3996f6a88c7a4f24b673809aa50897fb2615691 2021-08-26T09:00:30+00:00 lcnr rust@lcnr.de 2021-07-17T16:48:07+00:00 urn:sha1:ab9108b70f25ecd9cce1ab756b82cb00de6c6927 2021-08-15T20:17:37+00:00 Aaron Hill aa1ronham@gmail.com 2021-08-12T20:30:40+00:00 urn:sha1:a895069c5023a82e9316d21854a81172c69d1418 Fixes #85019 A `SourceFile` created during compilation may have a relative path (e.g. if rustc itself is invoked with a relative path). When we write out crate metadata, we convert all relative paths to absolute paths using the current working direction. However, the working directory is not included in the crate hash. This means that the crate metadata can change while the crate hash remains the same. Among other problems, this can cause a fingerprint mismatch ICE, since incremental compilation uses the crate metadata hash to determine if a foreign query is green. This commit moves the field holding the working directory from `Session` to `Options`, including it as part of the crate hash. 2021-08-14T07:01:36+00:00 bors bors@rust-lang.org 2021-08-14T07:01:36+00:00 urn:sha1:99efc51dae1dbe9d741707a7ddef84c29e654df5 Name the captured upvars for closures/generators in debuginfo Previously, debuggers print closures as something like ``` y::main::closure-0 (0x7fffffffdd34) ``` The pointer actually references to an upvar. It is not very obvious, especially for beginners. It's because upvars don't have names before, as they are packed into a tuple. This PR names the upvars, so we can expect to see something like ``` y::main::closure-0 {_captured_ref__b: 0x[...]} ``` r? `@tmandry` Discussed at https://github.com/rust-lang/rust/pull/84752#issuecomment-831639489 . 2021-08-04T13:51:30+00:00 Tomasz Miąsko tomasz.miasko@gmail.com 2021-08-01T00:00:00+00:00 urn:sha1:77e5e17231af060cc5ab17ec63494064ecc51076 Implement inbounds_gep using LLVMBuildInBoundsGEP2 which takes an explicit type argument instead of deriving it from a pointer type. 2021-07-09T20:14:44+00:00 Nikita Popov nikita.ppv@gmail.com 2021-07-04T16:53:04+00:00 urn:sha1:4560efe46c476cf794fa0ce4efb8db5aa55a3351 This makes load generation compatible with opaque pointers. The generation of nontemporal copies still accesses the pointer element type, as fixing this requires more movement. 2021-07-09T15:09:50+00:00 lrh2000 lrh2000@pku.edu.cn 2021-07-09T13:00:51+00:00 urn:sha1:0cb6f07ef2690b9ad5941c33a0928bf72788829d 2021-07-09T15:09:48+00:00 lrh2000 lrh2000@pku.edu.cn 2021-05-15T11:01:13+00:00 urn:sha1:cda90f55419ce449f3a9db327465d9b2ae7dfce9 - Closures in external crates may get compiled in because of monomorphization. We should store names of captured variables in `optimized_mir`, so that they are written into the metadata file and we can use them to generate debuginfo. - If there are breakpoints inside closures, the names of captured variables stored in `optimized_mir` can be used to print them. Now the name is more precise when disjoint fields are captured. 2021-07-09T15:06:53+00:00 lrh2000 lrh2000@pku.edu.cn 2021-05-05T15:50:44+00:00 urn:sha1:29856acffeb87541bb167c33f4fdb13c31ba6de0 Previously, debuggers print closures as something like ``` y::main::closure-0 (0x7fffffffdd34) ``` The pointer actually references to an upvar. It is not very obvious, especially for beginners. It's because upvars don't have names before, as they are packed into a tuple. This commit names the upvars, so we can expect to see something like ``` y::main::closure-0 {_captured_ref__b: 0x[...]} ```