- 12 8月, 2015 7 次提交
-
-
由 Alex Crichton 提交于
Also fixes a few outdated links.
-
由 Alex Crichton 提交于
-
由 Alex Crichton 提交于
Part of #22709. cc @Veedrac r? @bluss
-
由 Alex Crichton 提交于
As title :-) Part of #24407. r? @Manishearth
-
由 bors 提交于
The ideas is to use the span of the complete macro invocation if the span of a macro error is `DUMMY_SP`. fixes #7970
-
由 bors 提交于
Because I wanted to change the pretty test as little as possible I added `// compiler-flags: --crate-type=lib` to those test that failed because of a missing `main`. Passes `make check-stage1-pretty` locally. cc @nrc cc #27567
-
由 Guillaume Gomez 提交于
-
- 11 8月, 2015 33 次提交
-
-
由 bors 提交于
I have no idea how bors keeps working without this - I can only assume it's some peculiarity of how windows searches for DLLs. Without this change, running `make check` on windows will not correctly set PATH to include eg. `x86_64-pc-windows-gnu\stage1\bin\rustlib\x86_64-pc-windows-gnu\lib`, and when it tries to run eg. `stage1/test/stdtest-x86_64-pc-windows-gnu.exe`, it will fail because windows can't find the DLLs on which it relies. It seems to be just a mistake: when the equivalent was added for the branch that deals with unix-like platforms, the windows branch was left unchanged.
-
由 bors 提交于
- Successful merges: #27542, #27571, #27572, #27577, #27611, #27612, #27617, #27633, #27647, #27648, #27651 - Failed merges:
-
由 Manish Goregaokar 提交于
-
由 Manish Goregaokar 提交于
-
由 Manish Goregaokar 提交于
This is in line with other targets. Closes #27646
-
由 Manish Goregaokar 提交于
-
由 Manish Goregaokar 提交于
As title :-) Part of #24407. r? @Manishearth
-
由 Manish Goregaokar 提交于
The "nth" element can be confusing. In an array context, we know indexes start from 0 but one may believe this is not the case with "nth". For example, would `.nth(1)` return the first (1th/1st) or the second element? Rephrase a bit to be less confusing. r? @steveklabnik
-
由 Manish Goregaokar 提交于
The previous wording was confusing. While would we need to go through the whole list just to find the first code point? `chars()` being an iterator, we only need to walk from the beginning of the list. Note that I am not a native English speaker and I have still difficulties to spot if a "the" is needed somewhere. Feel free to take this PR as a mere suggestion. r? @steveklabnik
-
由 Manish Goregaokar 提交于
`FormatMessageW` always inserts trailing `\r\n` to system messages which is a minor annoyance when they're fed to `Debug` but can break formatting with `Display`. ```rust fn main() { use std::env; if let Err(err) = env::set_current_dir("???") { println!("{:#?}\n{}", err, err); } } ``` ```_ Error { repr: Os { code: 2, message: "The system cannot find the file specified.\r\n" } } The system cannot find the file specified. (os error 2) ```
-
由 Manish Goregaokar 提交于
-
由 Manish Goregaokar 提交于
Fixes #27303
-
由 Tim Neumann 提交于
-
由 Tim Neumann 提交于
-
由 bors 提交于
This means that we no longer need to ship the `llvm-ar.exe` binary in the MSVC distribution, and after a snapshot we can remove a good bit of logic from the makefiles!
-
由 bors 提交于
-
由 bors 提交于
This commit stabilizes the `std::time` module and the `Duration` type. `Duration::span` remains unstable, and the `Display` implementation for `Duration` has been removed as it is still being reworked and all trait implementations for stable types are de facto stable. This is a [breaking-change] to those using `Duration`'s `Display` implementation. I'm opening this PR as a platform for discussion - there may be some method renaming to do as part of the stabilization process.
-
由 Steven Fackler 提交于
-
由 bors 提交于
These two commits are aimed at "fixing" our usage of `dllexport` in the compiler. Currently we blanket apply this attribute to *everything* public in a crate, but this ends up with a few downsides: * Executables are larger than the should be as a result of thinking they should export everything * Native libraries aren't handled correctly because technically a statically included native library should be exported from a DLL in some cases. * Symbols don't actually need to be exported if they never end up in a DLL. The first commit adds a new unstable attribute, `#[linked_from]`, which is a way to tell the compiler what native library a block of symbols comes from. This is used to inform the compiler what set of native libraries are statically included in the rlib (or other output). This information is later used to export them from a DLL if necessary. Currently this is only used in a few places (such as the LLVM bindings) to get the compiler to link correctly. The second commit stops adding `dllexport` to all items in LLVM and instead explicitly telling the linker what symbols should be exported. We only need to do this when building a dynamic library, and otherwise we can avoid adding `dllexport` or telling the linker about exported symbols. As a testament to this change, the size of "Hello World" on MSVC drops from 1.2MB to 67KB as a result of this patch. This is because the linker can much more aggressively remove unused code. These commits do not yet attempt to fix our story with `dllimport`, and I'll leave that to a future PR and issue, for now though I'm going to say that this Closes #7196
-
由 Alex Crichton 提交于
Rust's current compilation model makes it impossible on Windows to generate one object file with a complete and final set of dllexport annotations. This is because when an object is generated the compiler doesn't actually know if it will later be included in a dynamic library or not. The compiler works around this today by flagging *everything* as dllexport, but this has the drawback of exposing too much. Thankfully there are alternate methods of specifying the exported surface area of a dll on Windows, one of which is passing a `*.def` file to the linker which lists all public symbols of the dynamic library. This commit removes all locations that add `dllexport` to LLVM variables and instead dynamically generates a `*.def` file which is passed to the linker. This file will include all the public symbols of the current object file as well as all upstream libraries, and the crucial aspect is that it's only used when generating a dynamic library. When generating an executable this file isn't generated, so all the symbols aren't exported from an executable. To ensure that statically included native libraries are reexported correctly, the previously added support for the `#[linked_from]` attribute is used to determine the set of FFI symbols that are exported from a dynamic library, and this is required to get the compiler to link correctly.
-
由 Alex Crichton 提交于
To correctly reexport statically included libraries from a DLL on Windows, the compiler will soon need to have knowledge about what symbols are statically included and which are not. To solve this problem a new unstable `#[linked_from]` attribute is being added and recognized on `extern` blocks to indicate which native library the symbols are coming from. The compiler then keeps track of what the set of FFI symbols are that are included statically. This information will be used in a future commit to configure how we invoke the linker on Windows.
-
由 Alex Crichton 提交于
This means that we no longer need to ship the `llvm-ar.exe` binary in the MSVC distribution, and after a snapshot we can remove a good bit of logic from the makefiles!
-
由 Steven Fackler 提交于
-
由 Steven Fackler 提交于
This commit stabilizes the `std::time` module and the `Duration` type. `Duration::span` remains unstable, and the `Display` implementation for `Duration` has been removed as it is still being reworked and all trait implementations for stable types are de facto stable. This is a [breaking-change] to those using `Duration`'s `Display` implementation.
-
由 Felix S. Klock II 提交于
-
由 Felix S. Klock II 提交于
Fix #27401.
-
由 Felix S. Klock II 提交于
This is a temporary workaround for the bugs that have been found in the implementation of PR #26173. * pnkfelix is unavailable in the short-term (i.e. for the next week) to fix them. * When the bugs are fixed, we will turn this back on by default. (If you want to play with the known-to-be-buggy optimization in the meantime, you can opt-back in via the debugging option that this commit is toggling.)
-
由 bors 提交于
This commit removes all morestack support from the compiler which entails: * Segmented stacks are no longer emitted in codegen. * We no longer build or distribute libmorestack.a * The `stack_exhausted` lang item is no longer required The only current use of the segmented stack support in LLVM is to detect stack overflow. This is no longer really required, however, because we already have guard pages for all threads and registered signal handlers watching for a segfault on those pages (to print out a stack overflow message). Additionally, major platforms (aka Windows) already don't use morestack. This means that Rust is by default less likely to catch stack overflows because if a function takes up more than one page of stack space it won't hit the guard page. This is what the purpose of morestack was (to catch this case), but it's better served with stack probes which have more cross platform support and no runtime support necessary. Until LLVM supports this for all platform it looks like morestack isn't really buying us much. cc #16012 (still need stack probes) Closes #26458 (a drive-by fix to help diagnostics on stack overflow) r? @brson
-
由 Alex Crichton 提交于
This commit removes all morestack support from the compiler which entails: * Segmented stacks are no longer emitted in codegen. * We no longer build or distribute libmorestack.a * The `stack_exhausted` lang item is no longer required The only current use of the segmented stack support in LLVM is to detect stack overflow. This is no longer really required, however, because we already have guard pages for all threads and registered signal handlers watching for a segfault on those pages (to print out a stack overflow message). Additionally, major platforms (aka Windows) already don't use morestack. This means that Rust is by default less likely to catch stack overflows because if a function takes up more than one page of stack space it won't hit the guard page. This is what the purpose of morestack was (to catch this case), but it's better served with stack probes which have more cross platform support and no runtime support necessary. Until LLVM supports this for all platform it looks like morestack isn't really buying us much. cc #16012 (still need stack probes) Closes #26458 (a drive-by fix to help diagnostics on stack overflow)
-
由 Tshepang Lekhonkhobe 提交于
-
由 Brian Anderson 提交于
-
由 bors 提交于
std: Allow ?Sized parameters in std::io::copy