about summary refs log tree commit diff
path: root/src/librustc_codegen_ssa
AgeCommit message (Collapse)AuthorLines
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-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
2019-07-25rustc: codegen: Build import library for all windows targetsHugo Beauzée-Luyssen-0/+20
So far it is assumed that using a DLL as a -l parameter argument is ok, but the assumption doesn't hold when compiling the native code with llvm. In which case, an import library is required, so let's build one This also requires the cargo counterpart to add the import library in the stamp files, at least when compiling libstd. Otherwise, the files don't get uplifted
2019-07-25std: Use native `#[thread_local]` TLS on wasmAlex Crichton-0/+7
This commit moves `thread_local!` on WebAssembly targets to using the `#[thread_local]` attribute in LLVM. This was recently implemented upstream and is [in the process of being documented][dox]. This change only takes affect if modules are compiled with `+atomics` which is currently unstable and a pretty esoteric method of compiling wasm artifacts. This "new power" of the wasm toolchain means that the old `wasm-bindgen-threads` feature of the standard library can be removed since it should now be possible to create a fully functioning threaded wasm module without intrusively dealing with libstd symbols or intrinsics. Yay! [dox]: https://github.com/WebAssembly/tool-conventions/pull/116
2019-07-25rustc: Update wasm32 support for LLVM 9Alex Crichton-201/+39
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-25Rollup merge of #62901 - petrochenkov:serde, r=CentrilMazdak Farrokhzad-3/+3
cleanup: Remove `extern crate serialize as rustc_serialize`s
2019-07-24fix unused importRalf Jung-1/+1
2019-07-24Merge `rustc_allocator` into `libsyntax_ext`Vadim Petrochenkov-4/+3
2019-07-24use PanicMessage type for MIR assertion errorsRalf Jung-5/+5
2019-07-24do not use InterpError::description outside librustc::mirRalf Jung-2/+2
2019-07-23Rollup merge of #62859 - spastorino:rename-to-as-ref, r=CentrilMark Rousskov-12/+12
Place::as_place_ref is now Place::as_ref r? @oli-obk
2019-07-23Rollup merge of #60951 - saleemjaffer:mir_better_error_enum, r=oli-obkMark Rousskov-3/+3
more specific errors in src/librustc/mir/interpret/error.rs Implements [this](https://github.com/rust-rfcs/const-eval/issues/4)
2019-07-23cleanup: Remove `extern crate serialize as rustc_serialize`sVadim Petrochenkov-3/+3
2019-07-23renames EvalErrorPanic to PanicMessageSaleem Jaffer-3/+3
2019-07-23moving some variants from InterpError to EvalErrorPanicSaleem Jaffer-3/+3
2019-07-22Place::as_place_ref is now Place::as_refSantiago Pastorino-12/+12
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-26 02:02:16 +0000