summary refs log tree commit diff
path: root/src/librustc_codegen_ssa
AgeCommit message (Collapse)AuthorLines
2019-09-09Convert Place's projection to a boxed sliceSantiago Pastorino-72/+72
2019-09-07Rollup merge of #64139 - Mark-Simulacrum:strip-legacy-proc-macro, r=petrochenkovMazdak Farrokhzad-6/+1
Migrate internal diagnostic registration to macro_rules Review is best done commit-by-commit. Fixes #64132.
2019-09-06rustc_codegen_llvm: give names to non-alloca variable values.Eduard-Mihai Burtescu-10/+24
2019-09-05Remove rustc_diagnostic_macros featureMark Rousskov-1/+0
2019-09-05Replace diagnostic plugins with macro_rulesMark Rousskov-5/+1
2019-09-05Rollup merge of #64003 - Dante-Broggi:place-align-in-layout, r=matthewjasperMazdak Farrokhzad-11/+22
place: Passing `align` = `layout.align.abi`, when also passing `layout` Of the calls changed: 7/12 use `align` = `layout.align.abi`. `from_const_alloc` uses `alloc.align`, but that is `assert_eq!` to `layout.align.abi`. only 4/11 use something interesting for `align`.
2019-09-04Remove `LocalInternedString` uses from `librustc_codegen_llvm`.Nicholas Nethercote-9/+8
2019-09-04Remove `LocalInternedString` uses from `librustc/ty/`.Nicholas Nethercote-2/+2
This is not a compelling change in isolation, but it is a necessary step.
2019-08-29`new_sized` is mostly used without alignDante-Broggi-8/+20
so rename it `new_sized_aligned`. 6/11 use `align` = `layout.align.abi`. `from_const_alloc` uses `alloc.align`, but that is `assert_eq!` to `layout.align.abi`. only 4/11 use something interesting for `align`.
2019-08-29`new_thin_place` is only used with `align` = `layout.align.abi`Dante-Broggi-3/+2
and is not `pub`.
2019-08-29Rollup merge of #63965 - loganwendholt:linker-script-fix, r=michaelwoeristerMazdak Farrokhzad-4/+7
Prevent syntax error in LD linker version script As discussed in #63925, there is an edge case in which an invalid LD version script is generated when building a `cdylib` with no exported symbols. This PR makes a slight modification to the LD version script generation by first checking to see if any symbols need to be exported. If not, the `global` section of the linker script is simply omitted, and the syntax error is averted.
2019-08-29Rollup merge of #63961 - JohnTitor:improve-require-lang-item, r=estebankMazdak Farrokhzad-1/+1
Add Option<Span> to `require_lang_item` Fixes #63954 I'm not sure where to take `Some(span)` or something so I use `None` in many places. r? @estebank
2019-08-28Auto merge of #63875 - philipc:issue-57822, r=michaelwoeristerbors-4/+10
debuginfo: give unique names to closure and generator types Closure types have been moved to the namespace where they are defined, and both closure and generator type names now include the disambiguator. This fixes an exception when lldb prints nested closures. Fixes #57822 I haven't included the `DW_AT_artificial` changes discussed in #57822 because they make the output worse IMO, but I can easily add these if still required. For example, for the new test case the output is now: ``` (lldb) p g (issue_57822::main::closure-1) $1 = closure-1(closure(1)) ``` but adding `DW_AT_artificial` changes this to: ``` (lldb) p g (issue_57822::main::closure-1) $0 = closure-1 { } ``` Note that nested generators didn't cause the exception. I haven't determined why, but I think it makes sense to add the disambiguator for them too. It feels like we still don't really understand why closures were causing an error though. r? @michaelwoerister
2019-08-27Prevent syntax error in ld linker version scriptLogan Wendholt-4/+7
2019-08-28Add Option<Span> to `require_lang_item`Yuki Okushi-1/+1
2019-08-27debuginfo: always include disambiguator in type namesPhilip Craig-10/+8
2019-08-25debuginfo: give unique names to closure and generator typesPhilip Craig-2/+10
Closure types have been moved to the namespace where they are defined, and both closure and generator type names now include the disambiguator. This fixes an exception when lldb prints nested closures. Fixes #57822
2019-08-22Handle statics in `Subst::subst()` by implementing `TypeFoldable`Wesley Wiser-9/+2
2019-08-22Fix tidyWesley Wiser-1/+0
2019-08-22Move def_id out add substsrefWesley Wiser-7/+20
2019-08-17Remove SyntaxContext from {ast, hir}::{GlobalAsm, InlineAsm}Matthew Jasper-1/+8
We now store it in the `Span` of the expression or item.
2019-08-16Remove redundant `ty` fields from `mir::Constant` and ↵Eduard-Mihai Burtescu-3/+3
`hair::pattern::PatternRange`.
2019-08-15hygiene: `ExpnInfo` -> `ExpnData`Vadim Petrochenkov-1/+1
For naming consistency with everything else in this area
2019-08-15hygiene: Remove `Option`s from functions returning `ExpnInfo`Vadim Petrochenkov-4/+1
The expansion info is not optional and should always exist
2019-08-15syntax_pos: Introduce a helper for checking whether a span comes from expansionVadim Petrochenkov-2/+2
2019-08-15Rollup merge of #63155 - mfkl:uwp-msvc, r=alexcrichtonMazdak Farrokhzad-0/+32
Add UWP MSVC targets Hi, - The README URI change is the correct one for VS2019 community edition, which I suspect most people would use. Doesn't _need_ to be merged though. - This https://github.com/rust-lang/rust/commit/5e6619edd1a3b5c3f85438166d4d32af49f800fd fixes the UWP build (msvc or not, doesn't matter). I suspect it broke with recent changes unnoticed because no CI. - Store lib location is found through the VCToolsInstallDir env variable. The end of the path is currently for the VS2019 store lib locations only. - I could not test the aarch64_uwp_windows_msvc target because the rust build script does not currently support arm64 msvc AFAIU.
2019-08-13review feedback: add comments and use local flavor variableMartin Finkel-1/+4
2019-08-12review feedback: move uwp link code to get_linkerMartin Finkel-13/+28
2019-08-11Rollup merge of #63464 - Mark-Simulacrum:deref-instance, r=eddybMark Rousskov-3/+3
Copy ty::Instance instead of passing by reference ty::Instance is small and Copy, we should not be adding additional indirection. Fixes #63409. r? @eddyb
2019-08-11Copy ty::Instance instead of passing by referenceMark Rousskov-3/+3
ty::Instance is small and Copy, we should not be adding additional indirection.
2019-08-10Derive Debug for CrateInfobjorn3-0/+1
2019-08-08Use associated_type_bounds where applicable - closes #61738Ilija Tovilo-2/+3
2019-08-08move store lib probing code to librustc_codegen_ssaMartin Finkel-0/+14
2019-08-07Auto merge of #63152 - estebank:big-array, r=oli-obkbors-13/+30
Always error on `SizeOverflow` during mir evaluation Fix #55878, fix #25116. r? @oli-obk
2019-08-05Fiddle param env through to `try_eval_bits` in most placesOliver Scherer-4/+4
2019-08-05Don't abort on unevaluated constants without at least tryting to eval themOliver Scherer-4/+4
2019-08-04tweak output and testsEsteban Küber-8/+19
2019-08-04review comments: clean upEsteban Küber-10/+5
2019-08-03Simplify change to layout_ofEsteban Küber-1/+0
2019-08-03Point to local place span on "type too big" errorEsteban Küber-5/+17
2019-08-02CTFE: simplify Value type by not checking for alignmentRalf Jung-5/+4
2019-08-02Rollup merge of #62969 - saleemjaffer:declutter_interperror, r=RalfJungMazdak Farrokhzad-3/+3
Changing the structure of `mir::interpret::InterpError` Implements [this](https://github.com/rust-rfcs/const-eval/issues/4#issuecomment-514559965)
2019-07-30Auto merge of #62766 - alexcrichton:stabilize-pipelined-compilation, r=oli-obkbors-1/+1
rustc: Stabilize options for pipelined compilation This commit stabilizes options in the compiler necessary for Cargo to enable "pipelined compilation" by default. The concept of pipelined compilation, how it's implemented, and what it means for rustc are documented in #60988. This PR is coupled with a PR against Cargo (rust-lang/cargo#7143) which updates Cargo's support for pipelined compliation to rustc, and also enables support by default in Cargo. (note that the Cargo PR cannot land until this one against rustc lands). The technical changes performed here were to stabilize the functionality proposed in #60419 and #60987, the underlying pieces to enable pipelined compilation support in Cargo. The issues have had some discussion during stabilization, but the newly stabilized surface area here is: * A new `--json` flag was added to the compiler. * The `--json` flag can be passed multiple times. * The value of the `--json` flag is a comma-separated list of directives. * The `--json` flag cannot be combined with `--color` * The `--json` flag must be combined with `--error-format=json` * The acceptable list of directives to `--json` are: * `diagnostic-short` - the `rendered` field of diagnostics will have a "short" rendering matching `--error-format=short` * `diagnostic-rendered-ansi` - the `rendered` field of diagnostics will be colorized with ansi color codes embedded in the string field * `artifacts` - JSON blobs will be emitted for artifacts being emitted by the compiler The unstable `-Z emit-artifact-notifications` and `--json-rendered` flags have also been removed during this commit as well. Closes #60419 Closes #60987 Closes #60988
2019-07-29use PanicInfo and UnsupportedOpInfoSaleem Jaffer-3/+3
2019-07-29Rollup merge of #62809 - alexcrichton:wasm-llvm-9, r=nikicMazdak Farrokhzad-201/+46
rustc: Update wasm32 support for LLVM 9 This commit brings in a number of minor updates for rustc's support for the wasm target which has changed in the LLVM 9 update. Notable updates include: * The compiler now no longer manually inserts the `producers` section, instead relying on LLVM to do so. LLVM uses the `llvm.ident` metadata for the `processed-by` directive (which is now emitted on the wasm target in this PR) and it uses debuginfo to figure out what `language` to put in the `producers` section. * Threaded WebAssembly code now requires different flags to be passed with LLD. In LLD we now pass: * `--shared-memory` - required since objects are compiled with atomics. This also means that the generated memory will be marked as `shared`. * `--max-memory=1GB` - required with the `--shared-memory` argument since shared memories in WebAssembly must have a maximum size. The 1GB number is intended to be a conservative estimate for rustc, but it should be overridable with `-C link-arg` if necessary. * `--passive-segments` - this has become the default for multithreaded memory, but when compiling a threaded module all data segments need to be marked as passive to ensure they don't re-initialize memory for each thread. This will also cause LLD to emit a synthetic function to initialize memory which users will have to arrange to call. * The `__heap_base` and `__data_end` globals are explicitly exported since they're now hidden by default due to the `--export` flags we pass to LLD.
2019-07-28Deny `unused_lifetimes` through rustbuildVadim Petrochenkov-1/+0
2019-07-28Remove lint annotations in specific crates that are already enforced by ↵Vadim Petrochenkov-11/+0
rustbuild Remove some random unnecessary lint `allow`s
2019-07-26rustc: Stabilize options for pipelined compilationAlex Crichton-1/+1
This commit stabilizes options in the compiler necessary for Cargo to enable "pipelined compilation" by default. The concept of pipelined compilation, how it's implemented, and what it means for rustc are documented in #60988. This PR is coupled with a PR against Cargo (rust-lang/cargo#7143) which updates Cargo's support for pipelined compliation to rustc, and also enables support by default in Cargo. (note that the Cargo PR cannot land until this one against rustc lands). The technical changes performed here were to stabilize the functionality proposed in #60419 and #60987, the underlying pieces to enable pipelined compilation support in Cargo. The issues have had some discussion during stabilization, but the newly stabilized surface area here is: * A new `--json` flag was added to the compiler. * The `--json` flag can be passed multiple times. * The value of the `--json` flag is a comma-separated list of directives. * The `--json` flag cannot be combined with `--color` * The `--json` flag must be combined with `--error-format=json` * The acceptable list of directives to `--json` are: * `diagnostic-short` - the `rendered` field of diagnostics will have a "short" rendering matching `--error-format=short` * `diagnostic-rendered-ansi` - the `rendered` field of diagnostics will be colorized with ansi color codes embedded in the string field * `artifacts` - JSON blobs will be emitted for artifacts being emitted by the compiler The unstable `-Z emit-artifact-notifications` and `--json-rendered` flags have also been removed during this commit as well. Closes #60419 Closes #60987 Closes #60988
2019-07-26Auto merge of #60260 - videolabs:rust_uwp2, r=alexcrichtonbors-0/+20
Add support for UWP targets Hi, This pull request aims at adding support for UWP (Universal Windows Apps) platform. A few notes: - This requires a very recent mingw-w64 version (containing this commit and the previous related ones: https://github.com/mirror/mingw-w64/commit/e8c433c871687a78408ae9b40ab7776577db908d#diff-eefdfbfe9cec5f4ebab88c9a64d423a9) - This was tested using LLVM/clang rather than gcc, and so far it assumes that LLVM/clang will be the native compiler. This is mostly due to the fact that the support for exceptions/stack unwinding for UWP got much more attention in libunwind - The "uwp" part of the target needs support for it in the `cc-rs` & `backtrace-rs` crates. I'll create the MR there right after I submit this one and will link everything together, but I'm not sure what's the correct way of dealing with external dependencies in the context of rust - Enabling import libraries and copying them across stages requires a change in cargo, for which I'll open a MR right after I submit this one as well - The i686 stack unwinding is unsupported for now, because LLVM assumes SjLj, while rust seems to assume SEH will be used. I'm unsure how to fix this Also, this is my first encounter with rust, so please bear with my code, it might not feel so idiomatic or even correct :) I'm pretty sure there's a way of doing things in a cleaner way when it comes to win/c.rs, maybe having a UWP & desktop specific modules, and import those conditionally? It doesn't feel right to sprinkle `#[cfg(...)]` all over the place Off course, I'll gladly update anything you see fit (to the extent of my abilities/knowledge :) )! Thanks,
2019-07-25Rollup merge of #62735 - petrochenkov:galloc, r=alexcrichtonMazdak Farrokhzad-4/+3
Turn `#[global_allocator]` into a regular attribute macro It was a 99% macro with exception of some diagnostic details. As a result of the change, `#[global_allocator]` now works in nested modules and even in nameless blocks. Fixes https://github.com/rust-lang/rust/issues/44113 Fixes https://github.com/rust-lang/rust/issues/58072