- 06 8月, 2017 4 次提交
-
-
由 bors 提交于
Bump 'src/doc/book' git submodule. Primarily to pick up this change: https://github.com/rust-lang/book/pull/866 ...to move this PR forward: https://github.com/rust-lang/rust/pull/43641
-
由 Corey Farwell 提交于
Primarily to pick up this change: https://github.com/rust-lang/book/pull/866 ...to move this PR forward: https://github.com/rust-lang/rust/pull/43641
-
由 bors 提交于
Fix typo in coerce_forced_unit docstring
-
由 Eric Daniels 提交于
-
- 05 8月, 2017 10 次提交
-
-
由 bors 提交于
String slice doc improvements. None
-
由 bors 提交于
APFloat: Rewrite It In Rust and use it for deterministic floating-point CTFE. As part of the CTFE initiative, we're forced to find a solution for floating-point operations. By design, IEEE-754 does not explicitly define everything in a deterministic manner, and there is some variability between platforms, at the very least (e.g. NaN payloads). If types are to evaluate constant expressions involving type (or in the future, const) generics, that evaluation needs to be *fully deterministic*, even across `rustc` host platforms. That is, if `[T; T::X]` was used in a cross-compiled library, and the evaluation of `T::X` executed a floating-point operation, that operation has to be reproducible on *any other host*, only knowing `T` and the definition of the `X` associated const (as either AST or HIR). Failure to uphold those rules allows an associated type (e.g. `<Foo as Iterator>::Item`) to be seen as two (or more) different types, depending on the current host, and such type safety violations typically allow writing of a `transmute` in safe code, given enough generics. The options considered by @rust-lang/compiler were: 1. Ban floating-point operations in generic const-evaluation contexts 2. Emulate floating-point operations in an uniformly deterministic fashion The former option may seem appealing at first, but floating-point operations *are allowed today*, so they can't be banned wholesale, a distinction has to be made between the code that already works, and future generic contexts. *Moreover*, every computation that succeeded *has to be cached*, otherwise the generic case can be reproduced without any generics. IMO there are too many ways it can go wrong, and a single violation can be enough for an unsoundness hole. Not to mention we may end up really wanting floating-point operations *anyway*, in CTFE. I went with the latter option, and seeing how LLVM *already* has a library for this exact purpose (as it needs to perform optimizations independently of host floating-point capabilities), i.e. `APFloat`, that was what I ended up basing this PR on. But having been burned by the low reusability of bindings that link to LLVM, and because I would *rather* the floating-point operations to be wrong than not deterministic or not memory-safe (`APFloat` does far more pointer juggling than I'm comfortable with), I decided to RIIR. This way, we have a guarantee of *no* `unsafe` code, a bit more control over the where native floating-point might accidentally be involved, and non-LLVM backends can share it. I've also ported all the testcases over, *before* any functionality, to catch any mistakes. Currently the PR replaces all CTFE operations to go through `apfloat::ieee::{Single,Double}`, keeping only the bits of the `f32` / `f64` memory representation in between operations. Converting from a string also double-checks that `core::num` and `apfloat` agree on the interpretation of a floating-point number literal, in case either of them has any bugs left around. r? @nikomatsakis f? @nagisa @est31 <hr/> Huge thanks to @edef1c for first demoing usable `APFloat` bindings and to @chandlerc for fielding my questions on IRC about `APFloat` peculiarities (also upstreaming some bugfixes).
-
由 Corey Farwell 提交于
-
由 Corey Farwell 提交于
-
由 bors 提交于
Uplift some comments to Doc comments
-
由 bors 提交于
Unskip some tests on AArch64 I've been running the test suite remotely on an Acer Chromebook R13 and natively on an ARM Juno developer board, both AArch64 devices. Most of the tests that are skipped on AArch64 are due to testing stdcall/fastcall/x86-specific code or the debugger, but I've found a few tests that could be enabled there. These have been skipped previously due to failing on the `aarch64-linux-android` and `mac-android` buildbots, more than 2 years ago (#23471, #23695). It seems we don't test those platforms any more, but as they do work on AArch64 Linux, I'd like to propose re-enabling them. All of them pass on my devices.
-
由 bors 提交于
Add L4Re Support in librustc_back Add experimental support for x86_64-unknown-l4re-uclibc target, which covers the L4 Runtime Environment. This pull request contains the changes that have to be made to librustc_back. It follows the changes humenda made in pull request https://github.com/rust-lang/libc/pull/591 to libc. Next steps will be the modifications to the needed libraries. (libstd, liballoc_system, libpanic_abort, libunwind) Thanks to humenda for reviewing.
-
由 bors 提交于
Fix some unaligned reads on SPARC in LTO This fixes #43593 by eliminating some undefined behavior.
-
由 bors 提交于
incr.comp.: Assert that no DepNode is re-opened (see issue #42298). This PR removes the last occurrence of DepNode re-opening and adds an assertion that prevents our doing so in the future too. The DepGraph should no be guaranteed to be cycle free. r? @nikomatsakis EDIT: Closes https://github.com/rust-lang/rust/issues/42298
-
由 bors 提交于
Link LLVM tools dynamically Set `LLVM_LINK_LLVM_DYLIB=ON` -- "If enabled, tools will be linked with the libLLVM shared library." Rust doesn't ship any of the LLVM tools, and only needs a few at all for some test cases, so statically linking the tools is just a waste of space. I've also had memory issues on slower machines with LLVM debuginfo enabled, when several tools start linking in parallel consuming several GBs each. With the default configuration, `build/x86_64-unknown-linux-gnu/llvm` was 1.5GB before, now down to 731MB. The difference is more drastic with `--enable-llvm-release-debuginfo`, from 28GB to "only" 13GB. This does not change the linking behavior of `rustc_llvm`.
-
- 04 8月, 2017 20 次提交
-
-
由 bors 提交于
Add a more precise error message for issue #35976 When trying to perform static dispatch on something which derefs to a trait object, and the target trait is not in scope, we had confusing error messages if the target method had a `Self: Sized` bound. We add a more precise error message in this case: "consider using trait ...". Fixes #35976. r? @nikomatsakis
-
由 Corey Farwell 提交于
-
由 Mátyás Mustoha 提交于
-
由 Oliver Schneider 提交于
-
由 bors 提交于
field does not exist error: note fields if Levenshtein suggestion fails When trying to access or initialize a nonexistent field, if we can't infer what field was meant (by virtue of the purported field in the source being a small Levenshtein distance away from an actual field, suggestive of a typo), issue a note listing all the available fields. To reduce terminal clutter, we don't issue the note when we have a `find_best_match_for_name` Levenshtein suggestion: the suggestion is probably right. The third argument of the call to `find_best_match_for_name` is changed to `None`, accepting the default maximum Levenshtein distance of one-third of the identifier supplied for correction. The previous value of `Some(name.len())` was overzealous, inappropriately very Levenshtein-distant suggestions when the attempted field access could not plausibly be a mere typo. For example, if a struct has fields `mule` and `phone`, but I type `.donkey`, I'd rather the error have a note listing that the available fields are, in fact, `mule` and `phone` (which is the behavior induced by this patch) rather than the error asking "did you mean `phone`?" (which is the behavior on master). The "only find fits with at least one matching letter" comment was accurate when it was first introduced in 09d99247 (January 2015), but is a vicious lie in its present context before a call to `find_best_match_for_name` and must be destroyed (replacing every letter is within a Levenshtein distance of name.len()). The present author claims that this suffices to resolve #42599.
-
由 scalexm 提交于
-
由 bors 提交于
Add MIR Validate statement This adds statements to MIR that express when types are to be validated (following [Types as Contracts](https://internals.rust-lang.org/t/types-as-contracts/5562)). Obviously nothing is stabilized, and in fact a `-Z` flag has to be passed for behavior to even change at all. This is meant to make experimentation with Types as Contracts in miri possible. The design is definitely not final. Cc @nikomatsakis @aturon
-
由 Josh Stone 提交于
-
由 Tobias Schaffner 提交于
Add support for x86_64-unknown-l4re-uclibc target, which covers the L4 Runtime Environment.
-
由 bors 提交于
Fix a number of failing tests on Solaris and SPARC
-
由 bors 提交于
Implement AsRawFd for Stdin, Stdout, and Stderr https://github.com/rust-lang/rfcs/issues/2074
-
由 Danek Duvall 提交于
-
由 Danek Duvall 提交于
This is a follow-up to f189d7a6 and 9d11b089. While `-z ignore` is what needs to be passed to the Solaris linker, because gcc is used as the default linker, both that form and `-Wl,-z -Wl,ignore` (including extra double quotes) need to be taken into account, which explains the more complex regular expression.
-
由 Ian Douglas Scott 提交于
-
由 Josh Stone 提交于
-
由 Danek Duvall 提交于
This is a follow-up to ea23e50f, which fixed it for the build.
-
由 Danek Duvall 提交于
This fixes a handful of long-failing tests.
-
由 Ian Douglas Scott 提交于
-
由 bors 提交于
Thread docs fix and improvements. None
-
由 bors 提交于
Update nomicon (This should have been in https://github.com/rust-lang/rust/pull/42959.)
-
- 03 8月, 2017 6 次提交
-
-
由 bors 提交于
Add regression test for #40510 This pull request adds a test case for issue #40510. Fixes #40510.
-
由 Michael Woerister 提交于
-
由 scalexm 提交于
-
由 scalexm 提交于
-
由 scalexm 提交于
When trying to perform static dispatch on something which derefs to a trait object, and the target trait is not in scope, we had confusing error messages if the target method had a `Self: Sized` bound. We add a more precise error message in this case: "consider using trait ...". Fixes #35976.
-
由 bors 提交于
extend config.toml doc for debug-assertions Even after I knew that I had to change config.toml to get any printing from debug! and trace!, going over the entire fail did not make it clear to me that `debug-assertions` is the option controlling that.
-