about summary refs log tree commit diff
path: root/src/test/run-fail/issue-2444.rs
AgeCommit message (Collapse)AuthorLines
2020-05-06Move tests from `test/run-fail` to UIYuki Okushi-15/+0
2018-12-25Remove licensesMark Rousskov-10/+0
2016-06-06run rustfmt on test/run-fail folderSrinivas Reddy Thatiparthy-3/+7
2015-03-26Mass rename uint/int to usize/isizeAlex Crichton-1/+1
Now that support has been removed, all lingering use cases are renamed.
2014-10-29Update infrastructure for fail -> panicSteve Klabnik-1/+1
This includes updating the language items and marking what needs to change after a snapshot. If you do not use the standard library, the language items you need to implement have changed. For example: ```rust #[lang = "fail_fmt"] fn fail_fmt() -> ! { loop {} } ``` is now ```rust #[lang = "panic_fmt"] fn panic_fmt() -> ! { loop {} } ``` Related, lesser-implemented language items `fail` and `fail_bounds_check` have become `panic` and `panic_bounds_check`, as well. These are implemented by `libcore`, so it is unlikely (though possible!) that these two renamings will affect you. [breaking-change] Fix test suite
2014-10-29Rename fail! to panic!Steve Klabnik-1/+1
https://github.com/rust-lang/rfcs/pull/221 The current terminology of "task failure" often causes problems when writing or speaking about code. You often want to talk about the possibility of an operation that returns a Result "failing", but cannot because of the ambiguity with task failure. Instead, you have to speak of "the failing case" or "when the operation does not succeed" or other circumlocutions. Likewise, we use a "Failure" header in rustdoc to describe when operations may fail the task, but it would often be helpful to separate out a section describing the "Err-producing" case. We have been steadily moving away from task failure and toward Result as an error-handling mechanism, so we should optimize our terminology accordingly: Result-producing functions should be easy to describe. To update your code, rename any call to `fail!` to `panic!` instead. Assuming you have not created your own macro named `panic!`, this will work on UNIX based systems: grep -lZR 'fail!' . | xargs -0 -l sed -i -e 's/fail!/panic!/g' You can of course also do this by hand. [breaking-change]
2014-09-19Add enum variants to the type namespaceNick Cameron-1/+1
Change to resolve and update compiler and libs for uses. [breaking-change] Enum variants are now in both the value and type namespaces. This means that if you have a variant with the same name as a type in scope in a module, you will get a name clash and thus an error. The solution is to either rename the type or the variant.
2014-06-11sync: Move underneath libstdAlex Crichton-2/+1
This commit is the final step in the libstd facade, #13851. The purpose of this commit is to move libsync underneath the standard library, behind the facade. This will allow core primitives like channels, queues, and atomics to all live in the same location. There were a few notable changes and a few breaking changes as part of this movement: * The `Vec` and `String` types are reexported at the top level of libcollections * The `unreachable!()` macro was copied to libcore * The `std::rt::thread` module was moved to librustrt, but it is still reexported at the same location. * The `std::comm` module was moved to libsync * The `sync::comm` module was moved under `sync::comm`, and renamed to `duplex`. It is now a private module with types/functions being reexported under `sync::comm`. This is a breaking change for any existing users of duplex streams. * All concurrent queues/deques were moved directly under libsync. They are also all marked with #![experimental] for now if they are public. * The `task_pool` and `future` modules no longer live in libsync, but rather live under `std::sync`. They will forever live at this location, but they may move to libsync if the `std::task` module moves as well. [breaking-change]
2014-02-14extern mod => extern crateAlex Crichton-1/+1
This was previously implemented, and it just needed a snapshot to go through
2014-02-05move concurrent stuff from libextra to libsyncJeremyLetang-3/+3
2013-10-22Drop the '2' suffix from logging macrosAlex Crichton-1/+1
Who doesn't like a massive renaming?
2013-09-30rfail: Remove usage of fmt!Alex Crichton-1/+1
2013-08-17Fix warnings it testsErick Tryzelaar-1/+1
2013-07-27Change concurrency primitives to standard naming conventionsSteven Stewart-Gallus-1/+1
To be more specific: `UPPERCASETYPE` was changed to `UppercaseType` `type_new` was changed to `Type::new` `type_function(value)` was changed to `value.method()`
2013-05-22test: Update tests to use the new syntax.Patrick Walton-2/+2
2013-02-13Remove die!, raplace invocations with fail! Issue #4524 pt 3Nick Desaulniers-1/+1
2013-02-01Remove fail keyword from lexer & parser and clean up remaining calls toNick Desaulniers-1/+1
fail Fix merge conflicts - Issue 4524
2013-01-29librustc: Disallow trait bounds in types, enumerations, and structure ↵Patrick Walton-1/+1
definitions. r=tjc
2012-12-13Rename Send trait to OwnedBrian Anderson-1/+1
2012-12-10Reliciense makefiles and testsuite. Yup.Graydon Hoare-0/+10
2012-09-11Convert 'use' to 'extern mod'. Remove old 'use' syntaxBrian Anderson-1/+1
2012-09-07Convert all kind bounds to camel case. Remove send, owned keywords.Brian Anderson-1/+1
2012-09-05test: "import" -> "use"Patrick Walton-1/+1
2012-08-26convert std::arc tests to use camel case ARCsBen Blum-1/+1
2012-08-10Split libcore/arc.rs: arc -> std::arc; exclusive -> unsafe::exclusiveBen Blum-0/+3
2012-07-05Arc requires send trait (issue #2788)Eric Holk-1/+1
2012-06-19Moved arc to libcore and added an arc that allows shared mutable state ↵Eric Holk-3/+0
through mutual exclusion.
2012-06-16Revert "Moved arc to libstd and added an arc that allows shared mutable ↵Tim Chevalier-0/+3
state through mutual exclusion." This reverts commit 015527b0cee0bc5cfaac8dd610035a0c1b2f8ea6.
2012-06-15Moved arc to libstd and added an arc that allows shared mutable state ↵Eric Holk-3/+0
through mutual exclusion.
2012-05-29modify shape code to only emit monomorphized enums (#2444)Niko Matsakis-0/+12
this is hacky, but shape code is going away anyway and I didn't want to invest too much effort into it