- 05 3月, 2015 4 次提交
-
-
由 Niko Matsakis 提交于
interface, so that we can perform this query without requiring a full trait def or set of supertraits.
-
由 Niko Matsakis 提交于
-
由 Niko Matsakis 提交于
-
由 Niko Matsakis 提交于
-
- 04 3月, 2015 10 次提交
-
-
由 bors 提交于
This allows to create proper debuginfo line information for items inlined from other crates (e.g. instantiations of generics). Only the codemap's 'metadata' is stored in a crate's metadata. That is, just filename, positions of line-beginnings, etc. but not the actual source code itself. Crate metadata size is increased by this change because spans in the encoded ASTs take up space now: ``` BEFORE AFTER libcore 36 MiB 39.6 MiB +10% libsyntax 51.1 MiB 60.5 MiB +18.4% libcollections 11.2 MiB 12.8 MiB +14.3% ``` This only affects binaries containing metadata (rlibs and dylibs), executables should not be affected in size. Fixes #19228 and probably #22226.
-
由 bors 提交于
-
由 bors 提交于
Signed-off-by: NLai Jiangshan <laijs@cn.fujitsu.com>
-
由 Michael Woerister 提交于
This allows to create proper debuginfo line information for items inlined from other crates (e.g. instantiations of generics). Only the codemap's 'metadata' is stored in a crate's metadata. That is, just filename, line-beginnings, etc. but not the actual source code itself. We are thus missing the opportunity of making Rust the first "open-source-only" programming language out there. Pity.
-
由 bors 提交于
Runway for RFC 809 (overloaded box/placement-in) by adding type annotations or explicit calls to `Box::new` where I found it necessary on PR #22086. I have broken this up into more than one PR because the entire commit chain (see PR #22086) is long, widespread and unwieldy to rebase frequently. To my knowledge this is not a breaking change. Also, there is in principle nothing stopping someone from reverting some/all of these annotations, since without the rest of the commit chain in #22086, the associated code would continue to compile. All I can do is ask: Try to discourage others from removing seemingly "unnecessary" uses of the `Box` type or the `Box::new()` function, until the rest of RFC 809 lands.
-
由 Felix S. Klock II 提交于
-
由 Felix S. Klock II 提交于
Many of the modifications putting in `Box::new` calls also include a pointer to Issue 22405, which tracks going back to `box <expr>` if possible in the future. (Still tried to use `Box<_>` where it sufficed; thus some tests still have `box_syntax` enabled, as they use a mix of `box` and `Box::new`.) Precursor for overloaded-`box` and placement-`in`; see Issue 22181.
-
由 Felix S. Klock II 提交于
(You shouldn't use it, but it is a semi-reasonable way to annotate types when necessary.)
-
由 Felix S. Klock II 提交于
This is the kind of change that one is expected to need to make to accommodate overloaded-`box`. ---- Note that this is not *all* of the changes necessary to accommodate Issue 22181. It is merely the subset of those cases where there was already a let-binding in place that made it easy to add the necesasry type ascription. (For unnamed intermediate `Box` values, one must go down a different route; `Box::new` is the option that maximizes portability, but has potential inefficiency depending on whether the call is inlined.) ---- There is one place worth note, `run-pass/coerce-match.rs`, where I used an ugly form of `Box<_>` type ascription where I would have preferred to use `Box::new` to accommodate overloaded-`box`. I deliberately did not use `Box::new` here, because that is already done in coerce-match-calls.rs. ---- Precursor for overloaded-`box` and placement-`in`; see Issue 22181.
-
由 bors 提交于
Make build timestamp files robust in face of concurrent source modification. Strategy: If the end goal is to touch e.g. `stamp.std`, then we first touch `stamp.std.start_time` before doing anything else. Then when the receipe finishes, we touch `stamp.std` using the timestamp from `stamp.std.start_time` as the reference time, and remove `stamp.std.start_time`. Fix #6518.
-
- 03 3月, 2015 26 次提交
-
-
由 bors 提交于
Rebase and follow-through on work done by @cmr and @aatch. Implements most of rust-lang/rfcs#560. Errors encountered from the checks during building were fixed. The checks for division, remainder and bit-shifting have not been implemented yet. See also PR #20795 cc @Aatch ; cc @nikomatsakis
-
由 Felix S. Klock II 提交于
Strategy: If the end goal is to touch e.g. `stamp.std`, then we first touch `stamp.std.start_time` before doing anything else. Then when the receipe finishes, we touch `stamp.std` using the timestamp from `stamp.std.start_time` as the reference time, and remove `stamp.std.start_time`. Fix #6518.
-
由 Felix S. Klock II 提交于
See buildlog here for evidence of such occurring: http://buildbot.rust-lang.org/builders/auto-linux-32-opt/builds/3910/steps/test/logs/stdio
-
由 bors 提交于
-
由 Manish Goregaokar 提交于
-
由 Manish Goregaokar 提交于
r? @Manishearth
-
由 Manish Goregaokar 提交于
Fixes #15778. r? @sfackler
-
由 Tobias Bucher 提交于
Conflicts: src/libstd/thread.rs
-
由 Manish Goregaokar 提交于
Reverts a small part of c74d49c8 because compilation pukes with warnings now.
-
由 Manish Goregaokar 提交于
Make `test/run-pass/backtrace.rs` more robust about own host environment Namely, I have been annoyed in the past when I have done `RUST_BACKTRACE=1 make check` only to discover (again) that such a trick causes this test to fail, because it assumes that the `RUST_BACKTRACE` environment variable is not set. Fix #22870
-
由 Manish Goregaokar 提交于
aarch64-linux-android build has been broken since #22839. Aarch64 android has _Unwind_GetIPInfo, so re-define this only for arm32 android. r? @alexcrichton
-
由 Manish Goregaokar 提交于
Unstable is the conservative choice. cc #22950.
-
由 Manish Goregaokar 提交于
`#[derive(Clone)]` unnecessarily requires the element type to also be `Clone`.
-
由 Manish Goregaokar 提交于
This changes the type of some public constants/statics in libunicode. Notably some `&'static &'static [(char, char)]` have changed to `&'static [(char, char)]`. The regexp crate seems to be the sole user of these, yet this is technically a [breaking-change]
-
由 Manish Goregaokar 提交于
Associated types are now treated as part of the public API by the privacy checker. If you were exposing a private type in your public API via an associated type, make that type public: ``` diff pub struct PublicType { .. } - struct Struct { .. } + pub struct Struct { .. } pub trait PublicTrait { type Output; fn foo(&self) -> Self::Output; } impl PublicTrait for PublicType { type Output = Struct; fn foo(&self) -> Struct { // `Struct` is part of the public API, it must be marked as `pub`lic .. } } ``` [breaking-change] --- r? @nikomatsakis closes #22912
-
由 Manish Goregaokar 提交于
Fix the return type in the comments. An old commit 082bfde4 (\"Fallout of std::str stabilization\") removed the example of FromStr::from_str(), this commit adds it back. But the example of StrExt::parse() is still kept with an additinal note. Signed-off-by: NLai Jiangshan <laijs@cn.fujitsu.com>
-
由 Manish Goregaokar 提交于
Its only user was lvalue_scratch_datum which is called with zero=true anymore, so it's effectively unused.
-
由 Manish Goregaokar 提交于
The API this exposes is a little strange (being attached to `static`s), so it makes sense to conservatively feature gate it. If it is highly popular, it is possible to reverse this gating.
-
由 Manish Goregaokar 提交于
* The lint visitor's visit_ty method did not recurse, and had a reference to the now closed #10894 * The newly enabled recursion has only affected the `deprectated` lint which now detects uses of deprecated items in trait impls and function return types * Renamed some references to `CowString` and `CowVec` to `Cow<str>` and `Cow<[T]>`, respectively, which appear outside of the crate which defines them * Replaced a few instances of `InvariantType<T>` with `PhantomData<Cell<T>>` * Disabled the `deprecated` lint in several places that reference/implement traits on deprecated items which will get cleaned up in the future * Unfortunately, this means that if a library declares `#![deny(deprecated)]` and marks anything as deprecated, it will have to disable the lint for any uses of said item, e.g. any impl the now deprecated item For any library that denies deprecated items but has deprecated items of its own, this is a [breaking-change] I had originally intended for the lint to ignore uses of deprecated items that are declared in the same crate, but this goes against some previous test cases that expect the lint to capture *all* uses of deprecated items, so I maintained the previous approach to avoid changing the expected behavior of the lint. Tested locally on OS X, so hopefully there aren't any deprecated item uses behind a `cfg` that I may have missed.
-
由 Manish Goregaokar 提交于
* Make num::UpperHex private. I was unable to determine why this struct is public. The num module itself is not public, and the UpperHex struct is not referenced anywhere in the core::fmt module. (Only the UpperHex trait is reference.) num::LowerHex is not public. * Remove the suffix parameters from the macros that generate integral display traits. The code to print the Debug::fmt suffixes was removed when Show was renamed to Debug. It was an intentional change. From RFC 0565: * Focus on the *runtime* aspects of a type; repeating information such as suffixes for integer literals is not generally useful since that data is readily available from the type definition. * Because Show was renamed to Debug, rename show! to debug!.
-
由 Manish Goregaokar 提交于
-
由 Felix S. Klock II 提交于
-
由 Felix S. Klock II 提交于
Suggestion was here: https://github.com/rust-lang/rust/pull/22532#discussion_r25505609
-
由 Felix S. Klock II 提交于
Added pair of regression tests that I should have made when I thought of doing this in the first place.
-
由 Felix S. Klock II 提交于
-
由 Felix S. Klock II 提交于
However, I left the ICEs rather than switching to nicer error reporting there; these cases *should* be detected prior to hitting trans, and thus ICE'ing here is appropriate. (So why switch to `eval_const_expr_partial`? Because I want to try to eliminate all uses of `eval_const_expr` entirely.)
-