Skip to content
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
wants to merge 304 commits into from

Conversation

vitiral
Copy link
Owner

@vitiral vitiral commented Oct 7, 2017

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.

spastorino and others added 30 commits September 27, 2017 15:11
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
kennytm and others added 13 commits October 8, 2017 13:38
…-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
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
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 vitiral closed this Oct 8, 2017
@vitiral vitiral deleted the incr_auto_assert branch October 8, 2017 15:31
@vitiral vitiral restored the incr_auto_assert branch October 8, 2017 15:31
@vitiral vitiral deleted the incr_auto_assert branch October 8, 2017 15:31
vitiral pushed a commit that referenced this pull request Jan 30, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.