- 21 5月, 2014 24 次提交
-
-
由 Huon Wilson 提交于
This defers to .fatal and .span_fatal for errors (rather than `fail!` which prints the ICE message). It also adds the span lookup when an id doesn't correspond to a block, to show what it is pointing at. It also makes the argument parser slightly looser, so that passing `--pretty flowgraph` recognises the `flowgraph` part and suggests to use an integer.
-
由 Huon Wilson 提交于
-
由 Huon Wilson 提交于
CamelCase all the way!
-
由 bors 提交于
StdWriter has .isatty(). StdReader can trivially vend the same function, and someone asked today on IRC how to call isatty() on stdin.
-
由 bors 提交于
Excluding the functions inherited from the cast module last week (with marked stability levels), these functions received the following treatment. * size_of - this method has become #[stable] * nonzero_size_of/nonzero_size_of_val - these methods have been removed * min_align_of - this method is now #[stable] * pref_align_of - this method has been renamed without the `pref_` prefix, and it is the "default alignment" now. This decision is in line with what clang does (see url linked in comment on function). This function is now #[stable]. * init - renamed to zeroed and marked #[stable] * uninit - marked #[stable] * move_val_init - renamed to overwrite and marked #[stable] * {from,to}_{be,le}{16,32,64} - all functions marked #[stable] * swap/replace/drop - marked #[stable] * size_of_val/min_align_of_val/align_of_val - these functions are marked #[unstable], but will continue to exist in some form. Concerns have been raised about their `_val` prefix.
-
由 Alex Crichton 提交于
Excluding the functions inherited from the cast module last week (with marked stability levels), these functions received the following treatment. * size_of - this method has become #[stable] * nonzero_size_of/nonzero_size_of_val - these methods have been removed * min_align_of - this method is now #[stable] * pref_align_of - this method has been renamed without the `pref_` prefix, and it is the "default alignment" now. This decision is in line with what clang does (see url linked in comment on function). This function is now #[stable]. * init - renamed to zeroed and marked #[stable] * uninit - marked #[stable] * move_val_init - renamed to overwrite and marked #[stable] * {from,to}_{be,le}{16,32,64} - all functions marked #[stable] * swap/replace/drop - marked #[stable] * size_of_val/min_align_of_val/align_of_val - these functions are marked #[unstable], but will continue to exist in some form. Concerns have been raised about their `_val` prefix. [breaking-change]
-
由 bors 提交于
This commit is part of the ongoing libstd facade efforts (cc #13851). The compiler now recognizes some language items as "extern { fn foo(...); }" and will automatically perform the following actions: 1. The foreign function has a pre-defined name. 2. The crate and downstream crates can only be built as rlibs until a crate defines the lang item itself. 3. The actual lang item has a pre-defined name. This is essentially nicer compiler support for the hokey core-depends-on-std-failure scheme today, but it is implemented the same way. The details are a little more hidden under the covers. In addition to failure, this commit promotes the eh_personality and rust_stack_exhausted functions to official lang items. The compiler can generate calls to these functions, causing linkage errors if they are left undefined. The checking for these items is not as precise as it could be. Crates compiling with `-Z no-landing-pads` will not need the eh_personality lang item, and crates compiling with no split stacks won't need the stack exhausted lang item. For ease, however, these items are checked for presence in all final outputs of the compiler. It is quite easy to define dummy versions of the functions necessary: #[lang = "stack_exhausted"] extern fn stack_exhausted() { /* ... */ } #[lang = "eh_personality"] extern fn eh_personality() { /* ... */ } cc #11922, rust_stack_exhausted is now a lang item cc #13851, libcollections is blocked on eh_personality becoming weak
-
由 Kevin Ballard 提交于
StdWriter has .isatty(). StdReader can trivially vend the same function, and someone asked today on IRC how to call isatty() on stdin.
-
由 bors 提交于
Make configure script respect (and save) values for `CC`, `CXX`, `CFLAGS` etc. I mostly tried to remain backwards compatible with old invocations of the `configure` script; if you do not want to use `CC` et al., you should not have to; you can keep using `--enable-clang` and/or `--enable-ccache`. The overall intention is to capture the following precedences for guessing the C compiler: 1. Value of `CC` at `make` invocation time. 2. Value of `CC` at `configure` invocation time. 3. Compiler inferred at configure invocation time (`gcc` or `clang`). The strategy is to check (at `configure` time) if each of the environment variables is set, and if so, save its value in a corresponding `CFG_` variable (e.g. `CFG_CC`). The `configure` script also does not attempt to infer the compiler if `CC` is set; but if `--enable-clang` was passed, then it *does* still attempt to validate that the clang version is compatible. Then, in the makefiles, if `CC` is not set but `CFG_CC` is, then we use the `CFG_CC` setting as `CC`. Fix #13805.
-
由 bors 提交于
Only an example was needed, as the ability to write uints into the string is already mentioned. Fix #7102.
-
由 bors 提交于
Tweak region inference to ignore constraints like `'a <= 'static`, since they have no value. This also ensures that we can handle some obscure cases of fn subtyping with bound regions that we didn't used to handle correctly. Fixes #13974.
-
由 Tobias Bucher 提交于
Only an example was needed, as the ability to write uints into the string is already mentioned. Fix #7102.
-
由 bors 提交于
Includes module docs for `cell`.
-
由 Felix S. Klock II 提交于
I mostly tried to remain backwards compatible with old invocations of the `configure` script; if you do not want to use `CC` et al., you should not have to; you can keep using `--enable-clang` and/or `--enable-ccache`. The overall intention is to capture the following precedences for guessing the C compiler: 1. Value of `CC` at make invocation time. 2. Value of `CC` at configure invocation time. 3. Compiler inferred at configure invocation time (`gcc` or `clang`). The strategy is to check (at `configure` time) if each of the environment variables is set, and if so, save its value in a corresponding `CFG_` variable (e.g. `CFG_CC`). Then, in the makefiles, if `CC` is not set but `CFG_CC` is, then we use the `CFG_CC` setting as `CC`. Also, I fold the potential user-provided `CFLAGS` and `CXXFLAGS` values into all of the per-platform `CFLAGS` and `CXXFLAGS` settings. (This was opposed to adding `$(CFLAGS)` in an ad-hoc manner to various parts of the mk files.) Fix #13805. ---- Note that if you try to set the compiler to clang via the `CC` and `CXX` environment variables, you will probably need to also set `CXXFLAGS` to `--enable-libcpp` so that LLVM will be configured properly. ---- Introduce CFG_USING_CLANG, which is distinguished from CFG_ENABLE_CLANG because the former represents "we think we're using clang, choose appropriate warning-control options" while the latter represents "we asked configure (or the host required) that we attempt to use clang, so check that we have an appropriate version of clang." The main reason I added this is that I wanted to allow the user to choose clang via setting the `CC` environment variable, but I did not want that method of selection to get confused with the user passing the `--enable-clang` option. ---- A digression: The `configure` script does not infer the compiler setting if `CC` is set; but if `--enable-clang` was passed, then it *does* still attempt to validate that the clang version is compatible. Supporting this required revising `CLANG_VERSION` check to be robust in face of user-provided `CC` value. In particular, on Travis, the `CC` is set to `gcc` and so the natural thing to do is to attempt to use `gcc` as the compiler, but Travis is also passing `--enable-clang` to configure. So, what is the right answer in the face of these contradictory requests? One approach would be to have `--enable-clang` supersede the setting for `CC` (and instead just call whatever we inferred for `CFG_CLANG`). That sounds maximally inflexible to me (pnkfelix): a developer requesting a `CC` value probably wants it respected, and should be able to set it to something else; it is harder for that developer to hack our configure script to change its inferred path to clang. A second approach would be to blindly use the `CC` value but keep going through the clang version check when `--enable-clang` is turned on. But on Travis (a Linux host), the `gcc` invocation won't print a clang version, so we would not get past the CLANG_VERSION check in that context. A third approach would be to never run the CLANG_VERSION check if `CC` is explicitly set. That is not a terrible idea; but if the user uses `CC` to pass in a path to some other version of clang that they want to test, probably should still send that through the `CLANG_VERSION` check. So in the end I (pnkfelix) took a fourth approach: do the CLANG_VERSION check if `CC` is unset *or* if `CC` is set to a string ending with `clang`. This way setting `CC` to things like `path/to/clang` or `ccache clang` will still go through the CLANG_VERSION check, while setting `CC` to `gcc` or some unknown compiler will skip the CLANG_VERSION check (regardless of whether the user passed --enable-clang to `configure`). ---- Drive-by fixes: * The call that sets `CFG_CLANG_VERSION` was quoting `"$CFG_CC"` in its invocation, but that does not play nicely with someone who sets `$CFG_CC` to e.g. `ccache clang`, since you do not want to intepret that whole string as a command. (On the other hand, a path with spaces might need the quoted invocation. Not sure which one of these corner use-cases is more important to support.) * Fix chk_cc error message to point user at `gcc` not `cc`.
-
由 bors 提交于
Edit: This now only covers refactoring to regex.
-
由 Brian Anderson 提交于
-
由 Brian Anderson 提交于
-
由 Brian Anderson 提交于
-
由 Brian Anderson 提交于
-
由 Brian Anderson 提交于
-
由 Brian Anderson 提交于
-
由 Brian Anderson 提交于
-
由 Kevin Butler 提交于
-
由 bors 提交于
The grammar for use declarations was outdated. Corrected some other mistakes.
-
- 20 5月, 2014 16 次提交
-
-
由 Piotr Czarnecki 提交于
The grammar for use declarations was outdated.
-
由 bors 提交于
When printing colored diagnostics, we need to reset the terminal before emitting the newline, not after. Otherwise it gets line-buffered and the color won't reset until the next line is printed or the compiler exits. Normally this isn't a problem, but when running rustc in parallel with other processes (e.g. `make -j4`) this can cause the color to leak to other lines.
-
由 bors 提交于
Closes #14278. Previously the type signatures of the ordering functions in `core::iter::order` took two iterators, but only if they were the same type of iterator. This commit loosens that restriction and allows different kinds of iterators (but with the same type of elements) to be compared.
-
由 bors 提交于
This is hard coding `Box` into this, as it doesn't seem to parse as `TyUniq` like `~` did. This may not be correct for all usages of the box keyword. Closes #14254.
-
由 Kevin Ballard 提交于
When printing colored diagnostics, we need to reset the terminal before emitting the newline, not after. Otherwise it gets line-buffered and the color won't reset until the next line is printed or the compiler exits. Normally this isn't a problem, but when running rustc in parallel with other processes (e.g. `make -j4`) this can cause the color to leak to other lines.
-
由 TyOverby 提交于
Previously the type signatures of the ordering functions in `core::iter::order` took two iterators, but only if they were the same type of iterator. This commit loosens that restriction and allows different kinds of iterators (but with the same type of elements) to be compared.
-
由 Kevin Butler 提交于
-
由 bors 提交于
The `init_to_vec` function in `collections::bitv` was exposed as an inherent method, but appears to just be a helper function for the `to_vec` method. This patch inlines the definition, removing `init_to_vec` from the public API. [breaking-change]
-
由 bors 提交于
This has no tests because it's near impossible to test -- since TestFn uses `proc`s, they can not be cloned or tested for equality. The only way to really test this is making sure that for a given number of shards `a`, sharding from 1 to `a` yields the complete set of tests. But `filter_tests` takes its vector by value and `proc`s cannot be compared. [breaking-change] Closes #10898
-
由 Corey Richardson 提交于
This has no tests because it's near impossible to test -- since TestFn uses `proc`s, they can not be cloned or tested for equality. The only way to really test this is making sure that for a given number of shards `a`, sharding from 1 to `a` yields the complete set of tests. But `filter_tests` takes its vector by value and `proc`s cannot be compared. [breaking-change] Closes #10898
-
由 Aaron Turon 提交于
The `init_to_vec` function in `collections::bitv` was exposed as an inherent method, but appears to just be a helper function for the `to_vec` method. This patch inlines the definition, removing `init_to_vec` from the public API. [breaking-change]
-
由 bors 提交于
Result.unwrap_or_handle() is the equivalent of Option.unwrap_or_else(). In the interests of naming consistency, call it the same thing. [breaking-change]
-
由 Kevin Ballard 提交于
Result.unwrap_or_handle() is the equivalent of Option.unwrap_or_else(). In the interests of naming consistency, call it the same thing. [breaking-change]
-
由 bors 提交于
-
由 Alex Crichton 提交于
This commit is part of the ongoing libstd facade efforts (cc #13851). The compiler now recognizes some language items as "extern { fn foo(...); }" and will automatically perform the following actions: 1. The foreign function has a pre-defined name. 2. The crate and downstream crates can only be built as rlibs until a crate defines the lang item itself. 3. The actual lang item has a pre-defined name. This is essentially nicer compiler support for the hokey core-depends-on-std-failure scheme today, but it is implemented the same way. The details are a little more hidden under the covers. In addition to failure, this commit promotes the eh_personality and rust_stack_exhausted functions to official lang items. The compiler can generate calls to these functions, causing linkage errors if they are left undefined. The checking for these items is not as precise as it could be. Crates compiling with `-Z no-landing-pads` will not need the eh_personality lang item, and crates compiling with no split stacks won't need the stack exhausted lang item. For ease, however, these items are checked for presence in all final outputs of the compiler. It is quite easy to define dummy versions of the functions necessary: #[lang = "stack_exhausted"] extern fn stack_exhausted() { /* ... */ } #[lang = "eh_personality"] extern fn eh_personality() { /* ... */ } cc #11922, rust_stack_exhausted is now a lang item cc #13851, libcollections is blocked on eh_personality becoming weak
-
由 bors 提交于
-