about summary refs log tree commit diff
path: root/src/test/compile-fail
AgeCommit message (Collapse)AuthorLines
2020-07-18rustc_metadata: Make crate loading fully speculativeVadim Petrochenkov-1/+1
2020-07-02Remove some `ignore-stage1` annotations.Eric Huss-2/+0
2020-06-28Update testsDylan MacKenzie-4/+4
2020-06-19Rollup merge of #72934 - christianpoveda:mut-borrows-in-consts, r=oli-obkManish Goregaokar-1/+1
forbid mutable references in all constant contexts except for const-fns PR to address #71212 cc: @ecstatic-morse
2020-06-19update diagnostics for &mut in constantsChristian Poveda-1/+1
2020-06-16bless allRalf Jung-1/+1
2020-05-04Add Option to Force Unwind TablesSam Elliott-0/+21
When panic != unwind, `nounwind` is added to all functions for a target. This can cause issues when a panic happens with RUST_BACKTRACE=1, as there needs to be a way to reconstruct the backtrace. There are three possible sources of this information: forcing frame pointers (for which an option exists already), debug info (for which an option exists), or unwind tables. Especially for embedded devices, forcing frame pointers can have code size overheads (RISC-V sees ~10% overheads, ARM sees ~2-3% overheads). In code, it can be the case that debug info is not kept, so it is useful to provide this third option, unwind tables, that users can use to reconstruct the call stack. Reconstructing this stack is harder than with frame pointers, but it is still possible. This commit adds a compiler option which allows a user to force the addition of unwind tables. Unwind tables cannot be disabled on targets that require them for correctness, or when using `-C panic=unwind`.
2020-04-29Bless testsDylan MacKenzie-2/+0
2020-04-14typeck: workaround WF hole in `to_const`.Eduard-Mihai Burtescu-0/+5
2020-03-26Update tests to use llvm_asm!Amanieu d'Antras-4/+4
2020-03-23Evaluate repeat expression lengths as late as possibleOliver Scherer-6/+1
2020-03-13Auto merge of #67502 - Mark-Simulacrum:opt-catch, r=Mark-Simulacrumbors-2/+0
Optimize catch_unwind to match C++ try/catch This refactors the implementation of catching unwinds to allow LLVM to inline the "try" closure directly into the happy path, avoiding indirection. This means that the catch_unwind implementation is (after this PR) zero-cost unless a panic is thrown. https://rust.godbolt.org/z/cZcUSB is an example of the current codegen in a simple case. Notably, the codegen is *exactly the same* if `-Cpanic=abort` is passed, which is clearly not great. This PR, on the other hand, generates the following assembly: ```asm # -Cpanic=unwind: push rbx mov ebx,0x2a call QWORD PTR [rip+0x1c53c] # <happy> mov eax,ebx pop rbx ret mov rdi,rax call QWORD PTR [rip+0x1c537] # cleanup function call call QWORD PTR [rip+0x1c539] # <unfortunate> mov ebx,0xd mov eax,ebx pop rbx ret # -Cpanic=abort: push rax call QWORD PTR [rip+0x20a1] # <happy> mov eax,0x2a pop rcx ret ``` Fixes #64224, and resolves #64222.
2020-03-05Remove eh_unwind_resume lang itemAmanieu d'Antras-2/+0
2020-03-02Remove chalk integrationCAD97-125/+0
2020-02-15remove no-longer-needed testRalf Jung-20/+0
2020-02-15fix compile-failRalf Jung-4/+4
2020-01-12Diagnostics should not end with a full stopvarkor-1/+1
2020-01-09Update testsVadim Petrochenkov-0/+2
2019-12-25Fix rebase and sort assoc type list for deterministic outputEsteban Küber-1/+1
2019-12-24Tweak errors for missing associated types and type parametersEsteban Küber-2/+2
2019-12-07Auto merge of #66927 - RalfJung:engines-dont-panic, r=oli-obkbors-1/+0
Miri core engine: use throw_ub instead of throw_panic See https://github.com/rust-lang/rust/issues/66902 for context: panicking is not really an "interpreter error", but just part of a normal Rust execution. This is a first step towards removing the `InterpError::Panic` variant: the core Miri engine does not use it any more. ConstProp and ConstEval still use it, though. This will be addressed in future PRs. From what I can tell, all the error messages this removes are actually duplicates. r? @oli-obk @wesleywiser
2019-12-02Correct other tests related to const_mut_refsChristian Poveda-1/+1
2019-12-01fix compile-fail testsRalf Jung-1/+0
2019-11-15A `Downcast` is now reached when const-checking a `for` loopDylan MacKenzie-0/+2
I believe this occurs because the old checker stopped processing basic blocks after a `SwitchInt`.
2019-11-13Bless less verbose error messagesDylan MacKenzie-7/+1
The MIR const-checker errors for if/match/loop are now delay span bugs, so nothing will be emitted unless the HIR checker misses something.
2019-11-13Bless const tests with improved diagnosticsDylan MacKenzie-0/+5
2019-10-22fix compile-fail testEsteban Küber-0/+1
2019-10-18[const-prop] Handle MIR Rvalue::AggregatesWesley Wiser-0/+1
2019-10-16Upgrade Emscripten targets to use upstream LLVM backendThomas Lively-1/+1
- Compatible with Emscripten 1.38.46-upstream or later upstream. - Refactors the Emscripten target spec to share code with other wasm targets. - Replaces the old incorrect wasm32 C call ABI with the correct one, preserving the old one as wasm32_bindgen_compat for wasm-bindgen compatibility. - Updates the varargs ABI used by Emscripten and deletes the old one. - Removes the obsolete wasm32-experimental-emscripten target. - Uses EMCC_CFLAGS on CI to avoid the timeout problems with #63649.
2019-10-05Revert "Auto merge of #63649 - tlively:emscripten-upstream-upgrade, ↵Tyler Mandry-1/+1
r=alexcrichton" This reverts commit 7870050796e5904a0fc85ecbe6fa6dde1cfe0c91, reversing changes made to 2e7244807a7878f6eca3eb7d97ae9b413aa49014.
2019-10-04Fix ABI, run and fix more tests, re-enable CI for PRsThomas Lively-1/+1
2019-09-23rustc: Fix mixing crates with different `share_generics`Alex Crichton-0/+1
This commit addresses #64319 by removing the `dylib` crate type from the list of crate type that exports generic symbols. The bug in #64319 arises because a `dylib` crate type was trying to export a symbol in an uptream crate but it miscalculated the symbol name of the uptream symbol. This isn't really necessary, though, since `dylib` crates aren't that heavily used, so we can just conservatively say that the `dylib` crate type never exports generic symbols, forcibly removing them from the exported symbol lists if were to otherwise find them. The fix here happens in two places: * First is in the `local_crate_exports_generics` method, indicating that it's now `false` for the `Dylib` crate type. Only rlibs actually export generics at this point. * Next is when we load exported symbols from upstream crate. If, for our compilation session, the crate may be included from a dynamic library, then its generic symbols are removed. When the crate was linked into a dynamic library its symbols weren't exported, so we can't consider them a candidate to link against. Overally this should avoid situations where we incorrectly calculate the upstream symbol names in the face of differnet `share_generics` options, ultimately... Closes #64319
2019-09-17Get rid of special const intrinsic query in favour of `const_eval`Oliver Scherer-0/+11
2019-08-06move error with diverging output to compile-failEsteban Küber-0/+7
2019-07-11rustc_mir: follow FalseUnwind's real_target edge in qualify_consts.Eduard-Mihai Burtescu-3/+8
2019-07-06Make WhileTrue into an EarlyLintPass lint.Mazdak Farrokhzad-0/+1
2019-06-20Auto merge of #60341 - mtak-:macos-tlv-workaround, r=alexcrichtonbors-3/+3
macos tlv workaround fixes: #60141 Includes: * remove dead code: `requires_move_before_drop`. This hasn't been needed for a while now (oops I should have removed it in #57655) * redox had a copy of `fast::Key` (not sure why?). That has been removed. * Perform a `read_volatile` on OSX to reduce `tlv_get_addr` calls per `__getit` from (4-2 depending on context) to 1. `tlv_get_addr` is relatively expensive (~1.5ns on my machine). Previously, in contexts where `__getit` was inlined, 4 calls to `tlv_get_addr` were performed per lookup. For some reason when `__getit` is not inlined this is reduced to 2x - and performance improves to match. After this PR, I have only ever seen 1x call to `tlv_get_addr` per `__getit`, and macos now benefits from situations where `__getit` is inlined. I'm not sure if the `read_volatile(&&__KEY)` trick is working around an LLVM bug, or a rustc bug, or neither. r? @alexcrichton
2019-06-19fix compile-fail test for targets without thread localstyler-4/+3
2019-06-13Create fewer basic blocks in match MIR loweringMatthew Jasper-0/+2
2019-05-29Update the rest of the test suites to use dynmemoryruins-1/+1
2019-05-15clang tidy fixestyler-1/+2
2019-05-15fix another testtyler-1/+1
2019-04-23Stabilize futures_apiTaylor Cramer-1/+1
2019-04-05Future-proof the Futures APITaylor Cramer-2/+2
2019-04-01Allow closure to unsafe fn coercionTaiki Endo-0/+5
2019-03-20Fix a bug in implied boundsscalexm-0/+28
2019-02-03Apply review suggestions and fix testsMatthias Einwag-2/+2
2019-01-09Stabilize `let` bindings and destructuring in constants and const fnOliver Scherer-1/+1
2018-12-31Rename and fix nolink-with-link-args testMika Lehtinen-13/+12
There are three problems with the nolink-with-link-args test: * The test fails when using MSVC. It's caused by the `linker-flavor=ld` flag which was added in #46291. * In its comment, this test tests that "link_args are indeed passed when nolink is specified", but the `nolink` attribute has been removed [a long time ago](https://github.com/rust-lang/rust/pull/12826). * Pattern has a small typo. At first I was going to completely remove this test, but there is [a closed pull request for that](https://github.com/rust-lang/rust/pull/21090). So: * rename the file as suggested in the closed PR * adjust the comment * fix typo in the pattern * add `ignore-msvc`.
2018-12-27Auto merge of #56999 - petrochenkov:macrecov2, r=estebankbors-0/+25
AST/HIR: Introduce `ExprKind::Err` for better error recovery in the front-end This way we can avoid aborting compilation if expansion produces errors and generate `ExprKind::Err`s instead.