https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=1.57.0 2021-10-11T04:31:47+00:00 2021-10-11T04:31:47+00:00 bors bors@rust-lang.org 2021-10-11T04:31:47+00:00 urn:sha1:9a757817c352801de8b0593728f8aee21e23cd53 Create more accurate debuginfo for vtables. Before this PR all vtables would have the same name (`"vtable"`) in debuginfo. Now they get an unambiguous name that identifies the implementing type and the trait that is being implemented. This is only one of several possible improvements: - This PR describes vtables as arrays of `*const u8` pointers. It would nice to describe them as structs where function pointer is represented by a field with a name indicative of the method it maps to. However, this requires coming up with a naming scheme that avoids clashes between methods with the same name (which is possible if the vtable contains multiple traits). - The PR does not update the debuginfo we generate for the vtable-pointer field in a fat `dyn` pointer. Right now there does not seem to be an easy way of getting ahold of a vtable-layout without also knowing the concrete self-type of a trait object. r? `@wesleywiser` 2021-10-08T08:33:47+00:00 Michael Woerister michaelwoerister@posteo 2021-10-06T12:26:50+00:00 urn:sha1:61c5a6d644e9e5c1995c33a2b07ab251702848ac Before this commit all vtables would have the same name "vtable" in debuginfo. Now they get a name that identifies the implementing type and the trait that is being implemented. 2021-10-03T14:08:54+00:00 Camille GILLOT gillot.camille@gmail.com 2020-11-14T15:48:54+00:00 urn:sha1:02025d86ac2294078f876015da59d56efe7bf59e 2021-10-01T21:17:19+00:00 Guillaume Gomez guillaume.gomez@huawei.com 2021-09-30T17:38:50+00:00 urn:sha1:759eba0a08ef80f958e671e822ad02e2b5409946 2021-09-18T01:41:33+00:00 Eduard-Mihai Burtescu eddyb@lyken.rs 2021-09-01T21:29:15+00:00 urn:sha1:c1837ef1c58edd48c81341126ecc94e7adc5bd3d 2021-09-18T01:41:29+00:00 Eduard-Mihai Burtescu eddyb@lyken.rs 2021-09-01T21:09:34+00:00 urn:sha1:e9b68304efc447a7bcd35b06511f6dfdfe9da16d 2021-09-13T12:42:06+00:00 bjorn3 bjorn3@users.noreply.github.com 2021-08-08T15:24:30+00:00 urn:sha1:8c7840e8cb700870854efa02cca817c7dd610698 Using symbol::Interner makes it very easy to mixup UniqueTypeId symbols with the global interner. In fact the Debug implementation of UniqueTypeId did exactly this. Using a separate interner type also avoids prefilling the interner with unused symbols and allow for optimizing the symbol interner for parallel access without negatively affecting the single threaded module codegen. 2021-09-09T08:41:19+00:00 Andreas Liljeqvist bonega@gmail.com 2021-08-29T09:06:55+00:00 urn:sha1:5b2f757dae374e22a7733f90af482f405bd426e9 fix fix Remove more refs and clones fix more fix 2021-09-05T16:14:41+00:00 bors bors@rust-lang.org 2021-09-05T16:14:41+00:00 urn:sha1:e2750baf53aaa60db95f10759f6cf9463dc5a6bd Provide `layout_of` automatically (given tcx + param_env + error handling). After #88337, there's no longer any uses of `LayoutOf` within `rustc_target` itself, so I realized I could move the trait to `rustc_middle::ty::layout` and redesign it a bit. This is similar to #88338 (and supersedes it), but at no ergonomic loss, since there's no funky `C: LayoutOf<Ty = Ty>` -> `Ty: TyAbiInterface<C>` generic `impl` chain, and each `LayoutOf` still corresponds to one `impl` (of `LayoutOfHelpers`) for the specific context. After this PR, this is what's needed to get `trait LayoutOf` (with the `layout_of` method) implemented on some context type: * `TyCtxt`, via `HasTyCtxt` * `ParamEnv`, via `HasParamEnv` * a way to transform `LayoutError`s into the desired error type * an error type of `!` can be paired with having `cx.layout_of(...)` return `TyAndLayout` *without* `Result<...>` around it, such as used by codegen * this is done through a new `LayoutOfHelpers` trait (and so is specifying the type of `cx.layout_of(...)`) When going through this path (and not bypassing it with a manual `impl` of `LayoutOf`), the end result is that only the error case can be customized, the query itself and the success paths are guaranteed to be uniform. (**EDIT**: just noticed that because of the supertrait relationship, you cannot actually implement `LayoutOf` yourself, the blanket `impl` fully covers all possible context types that could ever implement it) Part of the motivation for this shape of API is that I've been working on querifying `FnAbi::of_*`, and what I want/need to introduce for that looks a lot like the setup in this PR - in particular, it's harder to express the `FnAbi` methods in `rustc_target`, since they're much more tied to `rustc` concepts. r? `@nagisa` cc `@oli-obk` `@bjorn3` 2021-09-04T12:27:45+00:00 bors bors@rust-lang.org 2021-09-04T12:27:45+00:00 urn:sha1:226e181b80fa0be755872b66916ef7e704601ec2 Include debug info for the allocator shim Issue Details: In some cases it is necessary to generate an "allocator shim" to forward various Rust allocation functions (e.g., `__rust_alloc`) to an underlying function (e.g., `malloc`). However, since this allocator shim is a manually created LLVM module it is not processed via the normal module processing code and so no debug info is generated for it (if debugging info is enabled). Fix Details: * Modify the `debuginfo` code to allow creating debug info for a module without a `CodegenCx` (since it is difficult, and expensive, to create one just to emit some debug info). * After creating the allocator shim add in basic debug info.