forked from rust-lang/rust
-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Incremental compilation auto assert for rustc_clean/dirty #1
Closed
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
On Windows with the NTFS filesystem, `fs::copy` would return the sum of the lengths of all streams, which can be different from the length reported by `metadata` and thus confusing for users unaware of this NTFS peculiarity. This makes `fs::copy` return the same length `metadata` reports which is the value it used to return before PR rust-lang#26751. Note that alternate streams are still copied; their length is just not included in the returned value. This change relies on the assumption that the stream with index 1 is always the main stream in the `CopyFileEx` callback. I could not find any official document confirming this but empirical testing has shown this to be true, regardless of whether the alternate stream is created before or after the main stream. Resolves rust-lang#44532
Most of this info comes from camlorn's blog post on optimizing struct layout and the Rustonomicon.
* Change the context into the disabled directory. Now you can test containers which are disabled.
Add c_int for use in the compiler, assuming i32 for all targets as in libc.
To match the C signature, main() should be generated with C int type for the argc parameter and result, i.e. i32 instead of i64 on 64bit. That way it no longer relies on the upper 32 bits being zero, which I'm not sure is guaranteed by ABIs or startup code.
The local address's port is not 8080 in this example, that's the remote peer address port. On my machine, the local address is different every time, so I've changed `assert_eq` to only test the IP address
Add a missing import and remove unused imports
…-recursion, r=eddyb incr.comp.: Fix infinite recursion in Debug implementation of DepNode Small bug fix. Depends on rust-lang#44901 to land first.
…, r=steveklabnik Update trait summaries for std::fmt This patch is part of rust-lang#29355. r? @steveklabnik
Modify Rc/Arc language around mutability There are a few exceptions to the rule that Arc/Rc are immutable. Rather than dig into the details, add "generally" to hint at this difference, as it's kind of a distraction at this point in the docs. Additionally, Arc's docs were slightly different here generally, so add in both the existing language and the exception. Fixes rust-lang#44105
…ietMisdreavus Add missing links for AtomicBool r? @rust-lang/docs
…Oct, r=shepmaster Fix typo, per rust-lang#45057. This looks like a simple string -- one character -- fix. Given that I'm currently running low on battery, I have not actually compiled and tested this. But I am fully confident this passes muster. If not, I'll be maintainer-educated, yes? ;-)
…etrochenkov Add a semicolon to span for ast::Local
fmt: misc cleanup
Add read_to_end implementation to &[u8]'s Read impl The default impl for read_to_end does a bunch of bookkeeping that isn't necessary for slices and is about 4 times slower on my machine. The following benchmark takes about 30 ns before this change and about 7 ns after: ``` #[bench] fn bench_read_std(b: &mut Bencher) { let data = vec![0u8; 100]; let mut v = Vec::with_capacity(200); b.iter(|| { let mut s = data.as_slice(); v.clear(); s.read_to_end(&mut v).unwrap(); }); } ``` This solves the easy part of rust-lang#44819 (I think extending this to `Take<&[u8]> `would require specialization)
…lexcrichton Document that `-C ar=PATH` doesn't do anything Are there any plans to use an external archiver in the future? IIRC, it was used before, but its use was replaced with LLVM's built-in archive management machinery. I can't found a relevant PR though. EDIT: Found it - rust-lang#26926! The `-C` option is stable so it still can't be removed right away even if there are no plans to use it (but maybe it can be deprecated?). Target specifications have a field for archiver as well, which is unused too (these ones are unstable, so I guess it can be removed). r? @alexcrichton
enable strict alignment (+strict-align) on ARMv6 As discovered in rust-lang#44538 ARMv6 devices may or may not support unaligned memory accesses. ARMv6 Linux *seems* to have no problem with unaligned accesses but this is because the kernel is stepping in to fix each unaligned memory access -- this incurs in a performance penalty. This commit enforces aligned memory accesses on all our in-tree ARM targets that may be used with ARMv6 devices. This should improve performance of Rust programs on ARMv6 devices. For the record, clang also applies this attribute when targeting ARMv6 devices that are not running Darwin or NetBSD. closes rust-lang#44538 r? @alexcrichton
Rollup of 10 pull requests - Successful merges: rust-lang#45018, rust-lang#45042, rust-lang#45052, rust-lang#45053, rust-lang#45058, rust-lang#45060, rust-lang#45081, rust-lang#45083, rust-lang#45090, rust-lang#45094 - Failed merges:
Add builder for Solaris and merge it with Fuchsia's builder The new Solaris builder can be used to build rust-std. The dilos illumos distribution was chosen, because illumos is free software as opposed to Oracle Solaris and dilos is the only illumos distribution that supports x86_64 and sparcv9 at the same level.
Add -Zmutable-noalias flag We disabled noalias on mutable references a long time ago when it was clear that llvm was incorrectly handling this in relation to unwinding edges. Since then, a few things have happened: * llvm has cleaned up a bunch of the issues (I'm told) * we've added a nounwind codegen option As such, I would like to add this -Z flag so that we can evaluate if the codegen bugs still exist, and if this significantly affects the codegen of different projects, with an eye towards permanently re-enabling it (or at least making it a stable option).
vitiral
force-pushed
the
incr_auto_assert
branch
from
October 8, 2017 15:29
1d16ccf
to
dc1eeaf
Compare
vitiral
pushed a commit
that referenced
this pull request
Jan 30, 2019
Explain safety for `vec.set_len(0)`
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.
cc @michaelwoerister
Still waiting on rust-lang#44983 to merge
This is at a stage where I think it is mergable and I can continue to add the auto-detection to different nodes as we go along. On that note, I am comftorable taking a whole bunch of the issues from rust-lang#44924, since it is pretty smooth sailing with this infrastructure in plance.