about summary refs log tree commit diff
path: root/src/librustc_codegen_ssa
AgeCommit message (Collapse)AuthorLines
2019-03-09Rollup merge of #58518 - oli-obk:unreachable_result_errors, r=RalfJungMazdak Farrokhzad-7/+7
Use early unwraps instead of bubbling up errors just to unwrap in the end r? @RalfJung
2019-03-09Auto merge of #59012 - pietroalbini:rollup, r=pietroalbinibors-3/+4
Rollup of 24 pull requests Successful merges: - #58080 (Add FreeBSD armv6 and armv7 targets) - #58204 (On return type `impl Trait` for block with no expr point at last semi) - #58269 (Add librustc and libsyntax to rust-src distribution.) - #58369 (Make the Entry API of HashMap<K, V> Sync and Send) - #58861 (Expand where negative supertrait specific error is shown) - #58877 (Suggest removal of `&` when borrowing macro and appropriate) - #58883 (Suggest appropriate code for unused field when destructuring pattern) - #58891 (Remove stray ` in the docs for the FromIterator implementation for Option) - #58893 (race condition in thread local storage example) - #58906 (Monomorphize generator field types for debuginfo) - #58911 (Regression test for #58435.) - #58912 (Regression test for #58813) - #58916 (Fix release note problems noticed after merging.) - #58918 (Regression test added for an async ICE.) - #58921 (Add an explicit test for issue #50582) - #58926 (Make the lifetime parameters of tcx consistent.) - #58931 (Elide invalid method receiver error when it contains TyErr) - #58940 (Remove JSBackend from config.toml) - #58950 (Add self to mailmap) - #58961 (On incorrect cfg literal/identifier, point at the right span) - #58963 (libstd: implement Error::source for io::Error) - #58970 (delay_span_bug in wfcheck's ty.lift_to_tcx unwrap) - #58984 (Teach `-Z treat-err-as-bug` to take a number of errors to emit) - #59007 (Add a test for invalid const arguments) Failed merges: - #58959 (Add release notes for PR #56243) r? @ghost
2019-03-08Auto merge of #58985 - dlrobertson:fix_58980, r=alexregbors-9/+8
Fix segfaults in release build C-variadic fns `va_start` and `va_end` must be called to initialize/cleanup the "spoofed" `VaList` in a Rust defined C-variadic function even if the `VaList` is not used. r? @alexreg Fixes: #58980
2019-03-08Rollup merge of #58984 - estebank:multi-treat-err-as-bug, r=oli-obkPietro Albini-1/+1
Teach `-Z treat-err-as-bug` to take a number of errors to emit `-Z treat-err-as-bug` will cause `rustc` to panic after the first error is reported, like previously. `-Z treat-err-as-bug=2` will cause `rustc` to panic after 2 errors have been reported. Fix #58983.
2019-03-08Rollup merge of #58926 - gabi-250:tcx-lifetimes, r=petrochenkovPietro Albini-2/+2
Make the lifetime parameters of tcx consistent. I have implemented `codegen_allocator` for my backend, but I've had to make a small change to its signature in `ExtraBackendMethods`. I wonder if this change is justified, or if it is too specific to my use case to be useful to anyone else. `write_metadata` and `codegen_allocator` are both called from `codegen_crate` (in `librustc_codegen_ssa/base.rs`), and they both receive the same `tcx` as an argument: https://github.com/rust-lang/rust/blob/c196097e588b05e86b5ce6de992b2a6e6a7027bd/src/librustc_codegen_ssa/base.rs#L555-L557 and: https://github.com/rust-lang/rust/blob/c196097e588b05e86b5ce6de992b2a6e6a7027bd/src/librustc_codegen_ssa/base.rs#L640-L642 However, `codegen_allocator` accepts a `TyCtxt` with any lifetime parameters (`tcx: TyCtxt<'_, '_, '_>`), while `write_metadata` requires that the `tcx` argument is of type `TyCtxt<'b, 'gcx, 'gcx>`. In my implementation, I've found that it's necessary for `tcx` in `codegen_allocator` to also have the `<'b, 'gcx, 'gcx>` lifetime parameters. Have I misunderstood the purpose of the parameters of `TyCtxt`? I've read [here](https://rust-lang.github.io/rustc-guide/ty.html) that the last two parameters only need to be distinct if the function needs to be used during type inference, but I don't think that is the case here.
2019-03-08Rollup merge of #58906 - Nemo157:generator-state-debug-info, r=ZoxcPietro Albini-0/+1
Monomorphize generator field types for debuginfo Fixes #58888 r? @Zoxc
2019-03-07Fix segfaults in release build C-variadic fnsDan Robertson-9/+8
`va_start` and `va_end` must be called to initialize/cleanup the "spoofed" `VaList` in a Rust defined C-variadic function even if the `VaList` is not used.
2019-03-07HirIdification: replace NodeId method callsljedrz-2/+2
2019-03-06Make `-Z treat-err-as-bug` take a number of errors to be emittedEsteban Küber-1/+1
`-Z treat-err-as-bug=0` will cause `rustc` to panic after the first error is reported. `-Z treat-err-as-bug=2` will cause `rustc` to panic after 3 errors have been reported.
2019-03-05Use non_erasable_generics for codegenvarkor-1/+3
Co-Authored-By: Gabriel Smith <yodaldevoid@users.noreply.github.com>
2019-03-04Make the lifetime parameters of tcx consistent.Gabriela Alexandra Moldovan-2/+2
2019-03-04Use early unwraps instead of bubbling up errors just to unwrap in the endOliver Scherer-7/+7
2019-03-04Monomorphize generator field types for debuginfoWim Looman-0/+1
2019-03-03Auto merge of #58425 - wesleywiser:more_profiler_changes, r=michaelwoeristerbors-0/+28
[self-profiler] Make the profiler faster/more efficient Related to #58372 r? @michaelwoerister
2019-03-03Auto merge of #58673 - matthewjasper:typeck-ptr-coercions, r=pnkfelixbors-2/+4
[NLL] Type check operations with pointer types It seems these were forgotten about. Moving to `Rvalue::AddressOf` simplifies the coercions from references, but I want this to be fixed as soon as possible. r? @pnkfelix
2019-03-03Wrap the self-profiler in an `Arc<Mutex<>>`Wesley Wiser-0/+28
This will allow us to send it across threads and measure things like LLVM time.
2019-03-02Auto merge of #58836 - ljedrz:begone_NodeId, r=Zoxcbors-6/+6
Remove NodeId from even more HIR nodes The next iteration of HirIdification (#57578). Removes `NodeId` from: - [x] `StructField` - [x] `ForeignItem` - [x] `Item` - [x] `Pat` - [x] `FieldPat` - [x] `VariantData` - [x] `ImplItemId` (replaces it with `HirId`) - [x] `TraitItemId` (replaces it with `HirId`)
2019-03-02Auto merge of #58077 - Nemo157:generator-state-debug-info, r=Zoxcbors-4/+31
Add debug-info to access variables from generator state
2019-03-02hir: remove NodeId from StructFieldljedrz-6/+6
2019-03-01Auto merge of #58631 - spastorino:place2_1, r=oli-obkbors-15/+22
Put Local, Static and Promoted as one Base variant of Place Related to #52708 The `Place` 2.0 representation use a `Base` variant for `Local`, `Static` and `Promoted` so we start making this change in the current `Place` to make the following steps simpler. r? @oli-obk
2019-03-01Put Local, Static and Promoted as one Base variant of PlaceSantiago Pastorino-15/+22
2019-03-01Auto merge of #58408 - alexcrichton:update-llvm, r=michaelwoeristerbors-24/+1
rustc: Update LLVM, remove dead wasm code This commit updates the LLVM branch to the rebased version of the upstream release/8.x branch. This includes a wasm patch which means that the `rewrite_imports` pass in rustc is no longer needed (yay!) and we can instead rely on `wasm-import-module`, an attribute we're already emitting, to take care of all the work.
2019-02-27Rename variadic to c_variadicDan Robertson-4/+4
Function signatures with the `variadic` member set are actually C-variadic functions. Make this a little more explicit by renaming the `variadic` boolean value, `c_variadic`.
2019-02-27Refactor FunctionCx::codgen_terminatorDan Robertson-671/+771
- Move closures defined in codegen_terminator into a separate helper structure and implementation. - Create helper functions for each of the complex match arms on the terminators kind in codegen_terminator.
2019-02-27Support defining C compatible variadic functionsDan Robertson-10/+110
Add support for defining C compatible variadic functions in unsafe rust with extern "C".
2019-02-26rustc: Update LLVM, remove dead wasm codeAlex Crichton-24/+1
This commit updates the LLVM branch to the rebased version of the upstream release/8.x branch. This includes a wasm patch which means that the `rewrite_imports` pass in rustc is no longer needed (yay!) and we can instead rely on `wasm-import-module`, an attribute we're already emitting, to take care of all the work.
2019-02-26replace &'tcx Substs with SubstsRefcsmoe-8/+8
2019-02-25librustc_codegen_ssa: deny(elided_lifetimes_in_paths)Mazdak Farrokhzad-30/+34
2019-02-24Rollup merge of #58511 - oli-obk:const_to_op, r=RalfJungMazdak Farrokhzad-4/+4
Const to op simplification r? @RalfJung alternative to https://github.com/rust-lang/rust/pull/58486
2019-02-23Type check coercions to pointer typesMatthew Jasper-2/+4
2019-02-23Add debug-info to access variables from generator stateWim Looman-4/+31
2019-02-20Allow Self::Module to be mutated.Gabriela Alexandra Moldovan-6/+6
`codegen_allocator` and `write_metadata` mutate the underlying LLVM module. As such, it makes sense for these two functions to receive a mutable reference to the module (as opposed to an immutable one).
2019-02-16Reuse the `Pointer` type instead of passing reassembling it at many use sitesOliver Scherer-4/+4
2019-02-16Rollup merge of #58074 - scottmcm:stabilize-sort_by_cached_key, r=SimonSapinkennytm-1/+0
Stabilize slice_sort_by_cached_key I was going to ask on the tracking issue (https://github.com/rust-lang/rust/issues/34447), but decided to just send this and hope for an FCP here. The method was added last March by https://github.com/rust-lang/rust/pull/48639. Signature: https://doc.rust-lang.org/std/primitive.slice.html#method.sort_by_cached_key ```rust impl [T] { pub fn sort_by_cached_key<K, F>(&mut self, f: F) where F: FnMut(&T) -> K, K: Ord; } ``` That's an identical signature to the existing `sort_by_key`, so I think the questions are just naming, implementation, and the usual "do we want this?". The implementation seems to have proven its use in rustc at least, which many uses: https://github.com/rust-lang/rust/search?l=Rust&q=sort_by_cached_key (I'm asking because it's exactly what I just needed the other day: ```rust all_positions.sort_by_cached_key(|&n| data::CITIES.iter() .map(|x| *metric_closure.get_edge(n, x.pos).unwrap()) .sum::<usize>() ); ``` since caching that key is a pretty obviously good idea.) Closes #34447
2019-02-14Rollup merge of #58378 - alexcrichton:incremental-lto, r=michaelwoeristerMazdak Farrokhzad-20/+64
rustc: Implement incremental "fat" LTO Currently the compiler will produce an error if both incremental compilation and full fat LTO is requested. With recent changes and the advent of incremental ThinLTO, however, all the hard work is already done for us and it's actually not too bad to remove this error! This commit updates the codegen backend to allow incremental full fat LTO. The semantics are that the input modules to LTO are all produce incrementally, but the final LTO step is always done unconditionally regardless of whether the inputs changed or not. The only real incremental win we could have here is if zero of the input modules changed, but that's so rare it's unlikely to be worthwhile to implement such a code path. cc #57968 cc rust-lang/cargo#6643
2019-02-12Stabilize slice_sort_by_cached_keyScott McMurray-1/+0
2019-02-13Rollup merge of #58057 - michaelwoerister:stabilize-xlto, r=alexcrichtonMazdak Farrokhzad-19/+19
Stabilize linker-plugin based LTO (aka cross-language LTO) This PR stabilizes [linker plugin based LTO](https://github.com/rust-lang/rust/issues/49879), also known as "cross-language LTO" because it allows for doing inlining and other optimizations across language boundaries in mixed Rust/C/C++ projects. As described in the tracking issue, it works by making `rustc` emit LLVM bitcode instead of machine code, the same as `clang` does. A linker with the proper plugin (like LLD) can then run (Thin)LTO across all modules. The feature has been implemented over a number of pull requests and there are various [codegen](https://github.com/rust-lang/rust/blob/master/src/test/codegen/no-dllimport-w-cross-lang-lto.rs) and [run](https://github.com/rust-lang/rust/tree/master/src/test/run-make-fulldeps/cross-lang-lto-clang)-[make](https://github.com/rust-lang/rust/tree/master/src/test/run-make-fulldeps/cross-lang-lto-upstream-rlibs) [tests](https://github.com/rust-lang/rust/tree/master/src/test/run-make-fulldeps/cross-lang-lto) that make sure that it keeps working. It also works for building big projects like [Firefox](https://treeherder.mozilla.org/#/jobs?repo=try&revision=2ce2d5ddcea6fbff790503eac406954e469b2f5d). The PR makes the feature available under the `-C linker-plugin-lto` flag. As discussed in the tracking issue it is not cross-language specific and also not LLD specific. `-C linker-plugin-lto` is descriptive of what it does. If someone has a better name, let me know `:)`
2019-02-12Auto merge of #58341 - alexreg:cosmetic-2-doc-comments, r=steveklabnikbors-26/+26
Cosmetic improvements to doc comments This has been factored out from https://github.com/rust-lang/rust/pull/58036 to only include changes to documentation comments (throughout the rustc codebase). r? @steveklabnik Once you're happy with this, maybe we could get it through with r=1, so it doesn't constantly get invalidated? (I'm not sure this will be an issue, but just in case...) Anyway, thanks for your advice so far!
2019-02-12Fix some rebasing fallout regarding xLTO.Michael Woerister-1/+1
2019-02-12Stabilize linker-plugin based LTO.Michael Woerister-18/+18
2019-02-12rustc: Implement incremental "fat" LTOAlex Crichton-20/+64
Currently the compiler will produce an error if both incremental compilation and full fat LTO is requested. With recent changes and the advent of incremental ThinLTO, however, all the hard work is already done for us and it's actually not too bad to remove this error! This commit updates the codegen backend to allow incremental full fat LTO. The semantics are that the input modules to LTO are all produce incrementally, but the final LTO step is always done unconditionally regardless of whether the inputs changed or not. The only real incremental win we could have here is if zero of the input modules changed, but that's so rare it's unlikely to be worthwhile to implement such a code path. cc #57968 cc rust-lang/cargo#6643
2019-02-10rustc: doc commentsAlexander Regueiro-26/+26
2019-02-09librustc_codegen_ssa => 2018Taiki Endo-91/+75
2019-02-07Remove images' url to make it work even without internet connectionGuillaume Gomez-3/+1
2019-02-05Do not ICE in codegen given a extern_type staticDan Robertson-1/+18
The layout of a extern_type static is unsized, but may pass the Well-Formed check in typeck. As a result, we cannot assume that a static is sized when generating the `Place` for an r-value.
2019-02-01Auto merge of #57937 - denzp:nvptx, r=nagisabors-1/+132
NVPTX target specification This change adds a built-in `nvptx64-nvidia-cuda` GPGPU no-std target specification and a basic PTX assembly smoke tests. The approach is taken here and the target spec is based on `ptx-linker`, a project started about 1.5 years ago. Key feature: bitcode object files being linked with LTO into the final module on the linker's side. Prior to this change, the linker used a `ld` linker-flavor, but I think, having the special CLI convention is a more reliable way. Questions about further progress on reliable CUDA workflow with Rust: 1. Is it possible to create a test suite `codegen-asm` to verify end-to-end integration with LLVM backend? 1. How would it be better to organise no-std `compile-fail` tests: add `#![no_std]` where possible and mark others as `ignore-nvptx` directive, or alternatively, introduce `compile-fail-no-std` test suite? 1. Can we have the `ptx-linker` eventually be integrated as `rls` or `clippy`? Hopefully, this should allow to statically link against LLVM used in Rust and get rid of the [current hacky solution](https://github.com/denzp/rustc-llvm-proxy). 1. Am I missing some methods from `rustc_codegen_ssa::back::linker::Linker` that can be useful for bitcode-only linking? Currently, there are no major public CUDA projects written in Rust I'm aware of, but I'm expecting to have a built-in target will create a solid foundation for further experiments and awesome crates. Related to #38789 Fixes #38787 Fixes #38786
2019-01-29Provide PTXLinker with fallback to internal `target-cpu`Denys Zariaiev-0/+6
2019-01-28Adjust PTXLinker LTO logic and CLIDenys Zariaiev-9/+8
2019-01-28Auto merge of #55704 - Nemo157:pinned-generators, r=Zoxcbors-0/+7
Use pinning for generators to make trait safe I'm unsure whether there needs to be any changes to the actual generator transform. Tests are passing so the fact that `Pin<&mut T>` is fundamentally the same as `&mut T` seems to allow it to still work, but maybe there's something subtle here that could go wrong. This is specified in [RFC 2349 § Immovable generators](https://github.com/rust-lang/rfcs/blob/master/text/2349-pin.md#immovable-generators) (although, since that RFC it has become safe to create an immovable generator, and instead it's unsafe to resume any generator; with these changes both are now safe and instead the unsafety is moved to creating a `Pin<&mut [static generator]>` which there are safe APIs for). CC #43122
2019-01-27Update generator upvar debug infoWim Looman-0/+7
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-07-15 08:27:21 +0000