appveyor: Upgrade MinGW toolchains we use
In debugging #40546 I was able to reproduce locally finally using
the literal toolchain that the bots were using. I reproduced the error maybe 4
in 10 builds. I also have the 6.3.0 toolchain installed through `pacman` which
has yet to have a failed build.
When attempting to reproduce the bug with the toolchain that this commit
switches to I was unable to reproduce anything after a few builds. I have no
idea what the original problem was, but I'm hoping that it was just some random
bug fixed somewhere along the way.
I don't currently know of a technical reason to stick to the 4.9.2 toolchains we
were previously using. Historcal 5.3.* toolchains would cause llvm to segfault
(maybe a miscompile?) but this seems to have been fixed recently. To me if it
passes CI then I think we're good.
Closes#40546
In debugging #40546 I was able to reproduce locally finally using
the literal toolchain that the bots were using. I reproduced the error maybe 4
in 10 builds. I also have the 6.3.0 toolchain installed through `pacman` which
has yet to have a failed build.
When attempting to reproduce the bug with the toolchain that this commit
switches to I was unable to reproduce anything after a few builds. I have no
idea what the original problem was, but I'm hoping that it was just some random
bug fixed somewhere along the way.
I don't currently know of a technical reason to stick to the 4.9.2 toolchains we
were previously using. Historcal 5.3.* toolchains would cause llvm to segfault
(maybe a miscompile?) but this seems to have been fixed recently. To me if it
passes CI then I think we're good.
Closes#40546
travis: See if OSX generates crash dumps
I know for a fact we've had sccache segfault on various platforms and we've also
historically had a lot of problems with the linker on OSX. Let's just poke
around in the crash log directory to see if anything exists. If in the future we
see a build we think segfaulted *and* there's contents here then we can add some
bits that actually print out the logs.
The person who originally wrote the example forgot to include this attribute.
This caused Travis CI to fail on commit 9b0a4a4e97 (#40794), which just fixed
formatting in the description of std::process::Command::envs().
An empty line between the "Basic usage:" text and the example is required to
properly format the code. Without the empty line, the example is not formatted
as code.
Prior to this commit, most of the `BufRead` examples used `StdinLock` to
demonstrate how certain `BufRead` methods worked. Using `StdinLock` is
not ideal since:
* Relying on run-time data means we can't show concrete examples of how
these methods work up-front. The user is required to run them in order
to see how they behave.
* If the user tries to run an example in the playpen, it won't work
because the playpen doesn't support user input to stdin.
... even if contained `Vec` is not empty. E. g. for
```
let v = vec![10u8, 20];
let mut c = io::Cursor::new(v);
c.write_all(b"aaaa").unwrap();
println!("{:?}", c.into_inner());
```
result is
```
[97, 97, 97, 97]
```
and not
```
[10, 20, 97, 97, 97, 97]
```
I'm not really sure what we want the cadence here to be. We'll at the very least
update the Cargo submodule right before all releases, but otherwise I figured we
could just do it whenever needed or otherwise weekly (or something like that).
In any case, I don't have a super strong particular reason to do this, it's just
been a week or so since the release!
I realized that, even in the current system, such reads can't really do
any harm. Because they are not part of a task, they will occur no matter
what (only tasks can be skipped). If you leak the data you read into a
task, that is bad, but that is equally bad if you are in a task.
*Writes* to tracked state, on the other hand, should never occur except
from within a task (and the task then records what things you read to
compute it).
Once we complete the shift to on-demand, these properties will hold by
construction (because the on-demand struct enforces stateless tasks
where leaks are impossible -- except by having shared mutable state in
the tcx).
There's a suspicion that the OOM killer is killing sccache (maybe) so this adds
some logging to test out that assumption to see if anything dies and is logged
by `dmesg`
I know for a fact we've had sccache segfault on various platforms and we've also
historically had a lot of problems with the linker on OSX. Let's just poke
around in the crash log directory to see if anything exists. If in the future we
see a build we think segfaulted *and* there's contents here then we can add some
bits that actually print out the logs.
appveyor: Leverage auto-retry to upload to S3
This was recently implemented (appveyor/ci#1387) in response to one of our
feature requests, so let's take advantage of it! I'm going to optimistically
say...
Closes#39074
This commit deletes the internal liblog in favor of the implementation that
lives on crates.io. Similarly it's also setting a convention for adding crates
to the compiler. The main restriction right now is that we want compiler
implementation details to be unreachable from normal Rust code (e.g. requires a
feature), and by default everything in the sysroot is reachable via `extern
crate`.
The proposal here is to require that crates pulled in have these lines in their
`src/lib.rs`:
#![cfg_attr(rustbuild, feature(staged_api, rustc_private))]
#![cfg_attr(rustbuild, unstable(feature = "rustc_private", issue = "27812"))]
This'll mean that by default they're not using these attributes but when
compiled as part of the compiler they do a few things:
* Mark themselves as entirely unstable via the `staged_api` feature and the
`#![unstable]` attribute.
* Allow usage of other unstable crates via `feature(rustc_private)` which is
required if the crate relies on any other crates to compile (other than std).
There are now 3 queries:
- inherent_impls(def-id): for a given type, get a `Rc<Vec<DefId>>` with
all its inherent impls. This internally uses `crate_inherent_impls`,
doing some hacks to keep the current deps (which, btw, are not clearly
correct).
- crate_inherent_impls(crate): gathers up a map from types
to `Rc<Vec<DefId>>`, touching the entire krate, possibly generating
errors.
- crate_inherent_impls_overlap_check(crate): performs overlap checks
between the inherent impls for a given type, generating errors.
When the Range expression is the root of a constant, its node-id is
used for the def-id of the body, so it has to be preserved in the AST ->
HIR lowering.
Fixes#40749.
This "on-demand" task both checks for errors and computes the custom
unsized kind, if any. This task is only defined on impls of
`CoerceUnsized`; invoking it on any other kind of impl results in a bug.
This is just to avoid having an `Option`, could easily be changed.
Let's have this layer be towards the end as we're emprically changing sccache
more than we're changing the rest of the image, so this'll allow us to reuse as
much of the cached image as possible.
This alters the stdio code on Windows to always call `GetStdHandle` whenever the
stdio read/write functions are called as this allows us to track changes to the
value over time (such as if a process calls `SetStdHandle` while it's running).
Closes#40490
This was recently implemented (appveyor/ci#1387) in response to one of our
feature requests, so let's take advantage of it! I'm going to optimistically
say...
Closes#39074
Change object safety violation message
Hello!
This is my first pull request to rust so hopefully all goes well. This PR should fix issue #40670. I changed the error message in object_safety.rs and the corresponding compile-fail test in object-safety-supertrait-mentions-Self.rs.
Once the changes were made, I ran ```python x.py test src/tools/tidy``` and ```python x.py test```. Tidy passed and the compile-fail tests passed, however the test suite failed on the tcp tests as my machine has IPv6 disabled. I'm not sure what to do in this case besides letting travis run the suite against my changes. Please let me know if there's anything I can do to help further.
Thanks!
Mandeep
Fix doc error for ExactSizeIterator
The code example in the trait documentation of ExactSizeIterator
has an incorrect implementation of the len method that does not return
the number of times the example iterator 'Counter' will iterate. This
may confuse readers of the docs as the example code will compile but
doesn't uphold the trait's contract.
This is easily fixed by modifying the implementation of len and changing
the assert statement to actually assert the correct behaviour. I also
slightly modified a code comment to better reflect what the method
returns.
On-demandify associated item retrieval
Part of #40614.
I also started converting `adt_def`, but I decided to open a PR with just this bit first to make sure I'm going about this correctly.
r? @nikomatsakis
Add diagnostic for incorrect `pub (restriction)`
Given the following statement
```rust
pub (a) fn afn() {}
```
Provide the following diagnostic:
```rust
error: incorrect restriction in `pub`
--> file.rs:15:1
|
15 | pub (a) fn afn() {}
| ^^^
|
= help: some valid visibility restrictions are:
`pub(crate)`: visible only on the current crate
`pub(super)`: visible only in the current module's parent
`pub(in path::to::module)`: visible only on the specified path
help: to make this visible only to module `a`, add `in` before the path:
| pub (in a) fn afn() {}
```
Follow up to #40340, fix#40599, cc #32409.
Use the "official" cross compiler for NetBSD
The current NetBSD cross compiler is lacking, for example `std::thread` is not available (which causes problems for LLVM 4.0). This PR uses the official netbsd build system to compiler the cross compiler.
@alexcrichton: Can you please mirror `ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-7.0/source/sets/{src,gnusrc,sharesrc,syssrc}.tgz`. (Optionally you may want to use NetBSD versions 7.0.2 or 7.1, in that case you'll probably want to update the binary downloads used today as well).
I'll update the URL's afterwards (or feel free to use "allow edits from maintainers").
r? @alexcrichton
travis: Add timestamps to all build messages
When debugging why builds are taking so long it's often useful to get the
timestamp of all log messages as we're not always timing every tiny step of the
build. I wrote a [utility] for prepending a relative timestamp from the start of
a process which is now downloaded to the builders and is what we wrap the entire
build invocation in.
[utility]: https://github.com/alexcrichton/stamp-rsCloses#40577
rustc: Always emit the `uwtable` attribute on Windows
This commit alters the translation layer to unconditionally emit the `uwtable`
LLVM attribute on Windows regardless of the `no_landing_pads` setting.
Previously I believe we omitted this attribute as an optimization when the
`-Cpanic=abort` flag was passed, but this unfortunately caused problems for
Gecko.
It [was discovered] that there was trouble unwinding through Rust functions due
to foreign exceptions such as illegal instructions or otherwise in-practice
methods used to abort a process. In testing it looked like the major difference
between a working binary and a non-working binary is indeed this `uwtable`
attribute, but this PR has unfortunately not been thoroughly tested in terms of
compiling Gecko with `-C panic=abort` *and* this PR to see whether it works, so
this is still somewhat working on just suspicion.
[was discovered]: https://bugzilla.mozilla.org/show_bug.cgi?id=1302078
rustbuild: Don't hardcode 'nightly' for Cargo
It now follows rustc release trains. I also had to land this commit on beta (0a27a8713b) before https://github.com/rust-lang/rust/pull/40484 could land, so this is basically just a forward port (if you will) of that commit to master.
Given the following statement
```rust
pub (a) fn afn() {}
```
Provide the following diagnostic:
```rust
error: incorrect restriction in `pub`
--> file.rs:15:1
|
15 | pub (a) fn afn() {}
| ^^^^^^^
|
= help: some valid visibility restrictions are:
`pub(crate)`: visible only on the current crate
`pub(super)`: visible only in the current module's parent
`pub(in path::to::module)`: visible only on the specified path
help: to make this visible only to module `a`, add `in` before the path:
| pub (in a) fn afn() {}
```
Remove cruft from old `pub(path)` syntax.
Remove unused adt-def insertion by constructor DefIndex
It looks to me like ADT definitions weren't being looked up by constructor id, and a test run supports my theory.
In any case, I'm not sure it would have worked in its current configuration. If I understand correctly, the `adt_def` map entry from constructor id -> adt def would only be present after a successful call to `queries::adt_def::get` with the proper ADT `DefIndex`. Trying to look up an adt_def by the constructor index prior to a successful lookup by ADT index would fail since `item.kind` would be `EntryKind::Fn` (for the constructor function) and so would trigger the `bug!`.
r? @nikomatsakis
Some preparations for directly computing the ICH of crate-metadata.
This PR contains some small fixes in preparation for direct metadata hashing. It mostly just moves stuff into places where it will be needed (making the module structure slightly cleaner along the way) and it fixes some omissions in the MIR region eraser.
r? @nikomatsakis
Update gcc used for dist-x86-linux builds
GCC 4.7 is too old to build LLVM 4.0, so this PR updates to 4.8.
r? @alexcrichton (I'll ping you again once travis is green and the test commit is removed).
Correctly get source for metatdata-only crate type
Closes#40535
However, I'm not sure how to approach writing a regression test since I'm still working on a reduced test case from the code that caused the ICE in the first place. It's not enough to have an unknown `extern crate` in a metadata crate, it depends on a few extra arguments but I'm not sure which yet.
Also replaced the `unwrap()` with a more informative `expect()`.
r? @jseyfried
Introduce HirId, a replacement for ast::NodeId after lowering to HIR
This is the first step towards implementing #40303. This PR introduces the `HirId` type and generates a `HirId` for everything that would be assigned one (i.e. stuff in the HIR), but the HIR data types still use `NodeId` for now. Changing that is a big refactoring that I want to do in a separate PR.
A `HirId` uniquely identifies a node in the HIR of the current crate. It is composed of the `owner`, which is the `DefIndex` of the directly enclosing `hir::Item`, `hir::TraitItem`, or `hir::ImplItem` (i.e. the closest "item-like"), and the `local_id` which is unique within the given owner.
This PR is also running a number of consistency checks for the generated `HirId`s:
- Does `NodeId` in the HIR have a corresponding `HirId`?
- Is the `owner` part of each `HirId` consistent with its position in the HIR?
- Do the numerical values of the `local_id` part all lie within a dense range of integers?
cc @rust-lang/compiler
r? @eddyb or @nikomatsakis
