Update from original #1
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
fmt::Show is for debugging, and can and should be implemented for
all public types. This trait is used with `{:?}` syntax. There still
exists #[derive(Show)].
fmt::String is for types that faithfully be represented as a String.
Because of this, there is no way to derive fmt::String, all
implementations must be purposeful. It is used by the default format
syntax, `{}`.
This will break most instances of `{}`, since that now requires the type
to impl fmt::String. In most cases, replacing `{}` with `{:?}` is the
correct fix. Types that were being printed specifically for users should
receive a fmt::String implementation to fix this.
Part of #20013
[breaking-change]
link, but this does the same thing.
Conflicts: src/compiletest/runtest.rs src/libcore/fmt/mod.rs src/libfmt_macros/lib.rs src/libregex/parse.rs src/librustc/middle/cfg/construct.rs src/librustc/middle/dataflow.rs src/librustc/middle/infer/higher_ranked/mod.rs src/librustc/middle/ty.rs src/librustc_back/archive.rs src/librustc_borrowck/borrowck/fragments.rs src/librustc_borrowck/borrowck/gather_loans/mod.rs src/librustc_resolve/lib.rs src/librustc_trans/back/link.rs src/librustc_trans/save/mod.rs src/librustc_trans/trans/base.rs src/librustc_trans/trans/callee.rs src/librustc_trans/trans/common.rs src/librustc_trans/trans/consts.rs src/librustc_trans/trans/controlflow.rs src/librustc_trans/trans/debuginfo.rs src/librustc_trans/trans/expr.rs src/librustc_trans/trans/monomorphize.rs src/librustc_typeck/astconv.rs src/librustc_typeck/check/method/mod.rs src/librustc_typeck/check/mod.rs src/librustc_typeck/check/regionck.rs src/librustc_typeck/collect.rs src/libsyntax/ext/format.rs src/libsyntax/ext/source_util.rs src/libsyntax/ext/tt/transcribe.rs src/libsyntax/parse/mod.rs src/libsyntax/parse/token.rs src/test/run-pass/issue-8898.rs
Conflicts: src/librbml/lib.rs src/libserialize/json_stage0.rs src/libserialize/serialize_stage0.rs src/libsyntax/ast.rs src/libsyntax/ext/deriving/generic/mod.rs src/libsyntax/parse/token.rs
As per #20405. To be more precise, the changes just the processing of enums when the name is "RUST$ENCODED$ENUM$..." so it correctly parses when there is more than one number encoding the location of the field it's looking for to determine state of the enum
This calculates the width and height using the bounding box of the window in the buffer. Bounding box coordinates are inclusive so I have to add 1 to both dimensions.
This closes #20019, and should reject any where clauses placed on types not involving type parameters. r? @nikomatsakis
Conflicts: src/librustc/middle/mem_categorization.rs src/librustc/middle/ty.rs src/librustc_trans/trans/base.rs src/librustc_trans/trans/expr.rs src/librustc_trans/trans/foreign.rs src/librustc_typeck/check/mod.rs
This commit is a first past stabilization of `std::error`: * The module is stable. * The `FromError` trait and impls are stable * The `Error` trait itself is left unstable, pending current APIs and possible revisions during the alpha cycle.
This is a manual merge of #20627 and #20634 to avoid conflicts in rollup and also avoid one roundtrip. I've leave copyright to original author. If this one is moved to rollup original PR could be closed. cc @mneumann @alexcrichton r? Both FreeBSD and DragonFly define pthread_key_t as int, while Linux defines it as uint. As pthread_key_t is used as an opaque type and storage size of both int and uint are the same, this is rather a cosmetic change. iOS uses ulong (as OS X) so difference is critical on 64bit platforms.
There's been some debate over the precise form that these APIs should take, and they've undergone some changes recently, so these APIs are going to be left unstable for now to be fleshed out during the next release cycle.
Conflicts: src/libcollections/lib.rs src/librustc/lib.rs src/libserialize/lib.rs src/libstd/lib.rs
Conflicts: src/libcore/array.rs src/libcore/cell.rs src/libcore/prelude.rs src/libstd/path/posix.rs src/libstd/prelude/v1.rs src/test/compile-fail/dst-sized-trait-param.rs
Conflicts: src/libsyntax/parse/parser.rs
This commit takes a first pass at stabilizing `std::thread`: * It removes the `detach` method in favor of two constructors -- `spawn` for detached threads, `scoped` for "scoped" (i.e., must-join) threads. This addresses some of the surprise/frustrating debug sessions with the previous API, in which `spawn` produced a guard that on destruction joined the thread (unless `detach` was called). The reason to have the division in part is that `Send` will soon not imply `'static`, which means that `scoped` thread creation can take a closure over *shared stack data* of the parent thread. On the other hand, this means that the parent must not pop the relevant stack frames while the child thread is running. The `JoinGuard` is used to prevent this from happening by joining on drop (if you have not already explicitly `join`ed.) The APIs around `scoped` are future-proofed for the `Send` changes by taking an additional lifetime parameter. With the current definition of `Send`, this is forced to be `'static`, but when `Send` changes these APIs will gain their full flexibility immediately. Threads that are `spawn`ed, on the other hand, are detached from the start and do not yield an RAII guard. The hope is that, by making `scoped` an explicit opt-in with a very suggestive name, it will be drastically less likely to be caught by a surprising deadlock due to an implicit join at the end of a scope. * The module itself is marked stable. * Existing methods other than `spawn` and `scoped` are marked stable. The migration path is: ```rust Thread::spawn(f).detached() ``` becomes ```rust Thread::spawn(f) ``` while ```rust let res = Thread::spawn(f); res.join() ``` becomes ```rust let res = Thread::scoped(f); res.join() ``` [breaking-change]
Believe or not, `CreateProcess()` is racy if several threads create child processes: [0], [1], [2]. This caused some tests show crash dialogs during `make check-stage#-rpass`. More explanation: On Windows, `SetErrorMode()` controls display of error dialogs: it accepts new error mode and returns old error mode. The error mode is process-global and automatically inherited to child process when created. MSYS2 bash shell internally sets it to not show error dialogs, therefore `make check-stage#-rpass` should not show them either. However, [1] says that `CreateProcess()` internally invokes `SetErrorMode()` twice: at first it sets mode `0x8001` and saves original mode, and at second it restores original mode. So if two threads simultaneously call `CreateProcess()`, the first thread sets error mode to `0x8001` then the second thread recognizes that current error mode is `0x8001`. Therefore, The second thread will create process with wrong error mode. This really occurs inside `compiletest`: it creates several processes on each thread, so some `run-pass` tests are invoked with wrong error mode therefore show crash dialog. This commit adds `StaticMutex` for `CreateProcess()` call. This seems to fix the "dialog annoyance" issue. [0]: http://support.microsoft.com/kb/315939 [1]: https://code.google.com/p/nativeclient/issues/detail?id=2968 [2]: https://ghc.haskell.org/trac/ghc/ticket/2650
This bound is probably unintentional and is unnecessarily constricting.
Fix assertion in Mutex::destroy() on DragonFly (#20698) Reviewed-by: alexcrichton
mk: Update prerelase versioning to conform to semver Reviewed-by: alexcrichton
Because we are warning about unstable APIs and there are many of these yet, this creates a high likelyhood doc tests will fail. This doesn't seem right as a blanket policy to me anyway, though certainly we want it in std. Probably more appropriate to add a rustdoc option.
Because we are warning about unstable APIs and there are many of these yet, this creates a high likelyhood doc tests will fail. This doesn't seem right as a blanket policy to me anyway, though certainly we want it in std. Probably more appropriate to add a rustdoc option.
- target_word_size -> target_pointer_width - added armv7 and armv7s targets - enabled building binaries so tests could be run on a jailbroken device
Now it is possible to run tests on a jailbroken device
Changed alignment according to official Apple docs
Better iOS support Reviewed-by: alexcrichton
Make rustdoc use the `[_; N]` syntax instead of `[_, ..N]` Reviewed-by: sfackler
Link to http://rustbyexample.com/ Reviewed-by: steveklabnik
Add test for issue #20414 Reviewed-by: alexcrichton
The libstd definitions move to libcore, which causes some minor updates there.
This will temporarily prevent warnings generated from expanding to code that the test harness itself uses. This solution will require tweaking around the beta cycle, but it will prevent spurious warnings for now. Closes #20823
r? @alexcrichton. This passes tests for me.
This will temporarily prevent warnings generated from expanding to code that the test harness itself uses. This solution will require tweaking around the beta cycle, but it will prevent spurious warnings for now. Closes #20823
Here's my PR for the changes discussed in #19823. I decided to leave `_these_` types of italics the way there were because it differentiates the use of italics for emphasis from `*key term*` italics. Otherwise, bolded terms have been changed to italics, and single and double quotes have been changed appropriately, depending on their context (my judgement may not be the best, though). r? @steveklabnik (congratulations on #19897 being finalized and merged, by the way!)
arthurtw
pushed a commit
that referenced
this pull request
Jan 10, 2015
Fixes rust-lang#19707. In terms of output, it currently uses the form `argument #1`, `argument rust-lang#2`, etc. If anyone has any better suggestions I would be glad to consider them.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.