Some tests just add the extra errors, others I fix by doing some simple error recovery. I've tried to avoid doing too much in the hope of doing something more principled later.
In general error messages are getting worse at this stage, but I think in the long run they will get better.
cc https://github.com/rust-lang/rust/pull/31487#issuecomment-182945101
plugin-[breaking-change]
The first commit renames `ast::Pat_` to `ast::PatKind` and uses its variants in enum qualified form. I've also taken the opportunity and renamed `PatKind::Region` into `PatKind::Ref`.
The second commit splits `PatKind::Enum` into `PatKind::TupleStruct` and `PatKind::UnitStruct`.
So, pattern kinds now correspond to their struct/variant kinds - `Struct`, `TupleStruct` and `UnitStruct`.
@nikomatsakis @nrc @arielb1 Are you okay with this naming scheme?
An alternative possible naming scheme is `PatKind::StructVariant`, `PatKind::TupleVariant`, `PatKind::UnitVariant` (it's probably closer to the common use, but I like it less).
I intend to apply these changes to HIR later, they should not necessarily go in the same nightly with https://github.com/rust-lang/rust/pull/31487
r? @Manishearth
This commit is an implementation of [RFC 1415][rfc] which deprecates all types
in the `std::os::*::raw` modules.
[rfc]: https://github.com/rust-lang/rfcs/blob/master/text/1415-trim-std-os.md
Many of the types in these modules don't actually have a canonical platform
representation, for example the definition of `stat` on 32-bit Linux will change
depending on whether C code is compiled with LFS support or not. Unfortunately
the current types in `std::os::*::raw` are billed as "compatible with C", which
in light of this means it isn't really possible.
To make matters worse, platforms like Android sometimes define these types as
*smaller* than the way they're actually represented in the `stat` structure
itself. This means that when methods like `DirEntry::ino` are called on Android
the result may be truncated as we're tied to returning a `ino_t` type, not the
underlying type.
The commit here incorporates two backwards-compatible components:
* Deprecate all `raw` types that aren't in `std::os::raw`
* Expand the `std::os::*::fs::MetadataExt` trait on all platforms for method
accessors of all fields. The fields now returned widened types which are the
same across platforms (consistency across platforms is not required, however,
it's just convenient).
and two also backwards-incompatible components:
* Change the definition of all `std::os::*::raw` type aliases to
correspond to the newly widened types that are being returned on each
platform.
* Change the definition of `std::os::*::raw::stat` on Linux to match the LFS
definitions rather than the standard ones.
The breaking changes here will specifically break code that assumes that `libc`
and `std` agree on the definition of `std::os::*::raw` types, or that the `std`
types are faithful representations of the types in C. An [audit] has been
performed of crates.io to determine the fallout which was determined two be
minimal, with the two found cases of breakage having been fixed now.
[audit]: https://github.com/rust-lang/rfcs/pull/1415#issuecomment-180645582
---
Ok, so after all that, we're finally able to support LFS on Linux! This commit
then simultaneously starts using `stat64` and friends on Linux to ensure that we
can open >4GB files on 32-bit Linux. Yay!
Closes#28978Closes#30050Closes#31549
The BSD grep for "basic regex" don't support \| as alternate operator (at least under OpenBSD).
Use multiple -e arguments for expressing alternative. I have checked it under Linux (Debian).
This PR should make it easier to create a baseline x86 compiler as well as make cross-compilation possible through a separate set of rlibs.
Plus, a few Linux distributions (e.g. Debian) have voiced interest in having this target available.
I feel sorry for bothering you with such a literally one character changes. If it is counter productive feel free to point it out in the comments, that would be totally understandable. I could try to pack such a changes together in one PR to make them less distractive.
r? @steveklabnik
Not everyone knows this convention. We could just rename the variables in the
example, but since this notation is commonly used it's a good opportunity to
introduce it.
r? @steveklabnik
This is a minor change. Please see title. IMO this is important since this is the first instance when we talk about allocating a vector. Not saying that it is allocated on the stack here leaves room for speculation and this might put off some people (they might not even read the later sections which go into more detail about this).
`wrapping_shl` and `wrapping_shr` are easy to mistake for rotations, when in fact they work somewhat differently. The documentation currently available is a little sparse and easy to misinterpret, so I've added a warning to anyone who bumps into them that the equivalent rotate methods may actually be what they're looking for.
If it's deemed useful to add a symmetrical mention to the documentation for the `rotate_left` and `rotate_right` methods, I can certainly have a go at that, but my gut feeling is that people likely to want a rotate will already know about the wrapping-arithmetic methods, for example from writing CPU simulators.
This commit is an implementation of [RFC 1415][rfc] which deprecates all types
in the `std::os::*::raw` modules.
[rfc]: https://github.com/rust-lang/rfcs/blob/master/text/1415-trim-std-os.md
Many of the types in these modules don't actually have a canonical platform
representation, for example the definition of `stat` on 32-bit Linux will change
depending on whether C code is compiled with LFS support or not. Unfortunately
the current types in `std::os::*::raw` are billed as "compatible with C", which
in light of this means it isn't really possible.
To make matters worse, platforms like Android sometimes define these types as
*smaller* than the way they're actually represented in the `stat` structure
itself. This means that when methods like `DirEntry::ino` are called on Android
the result may be truncated as we're tied to returning a `ino_t` type, not the
underlying type.
The commit here incorporates two backwards-compatible components:
* Deprecate all `raw` types that aren't in `std::os::raw`
* Expand the `std::os::*::fs::MetadataExt` trait on all platforms for method
accessors of all fields. The fields now returned widened types which are the
same across platforms (consistency across platforms is not required, however,
it's just convenient).
and two also backwards-incompatible components:
* Change the definition of all `std::os::*::raw` type aliases to
correspond to the newly widened types that are being returned on each
platform.
* Change the definition of `std::os::*::raw::stat` on Linux to match the LFS
definitions rather than the standard ones.
The breaking changes here will specifically break code that assumes that `libc`
and `std` agree on the definition of `std::os::*::raw` types, or that the `std`
types are faithful representations of the types in C. An [audit] has been
performed of crates.io to determine the fallout which was determined two be
minimal, with the two found cases of breakage having been fixed now.
[audit]: https://github.com/rust-lang/rfcs/pull/1415#issuecomment-180645582
---
Ok, so after all that, we're finally able to support LFS on Linux! This commit
then simultaneously starts using `stat64` and friends on Linux to ensure that we
can open >4GB files on 32-bit Linux. Yay!
Closes#28978Closes#30050Closes#31549
<sup>**context:** moving back to a layered approach to type checking.</sup>
It looks like they'd not ended up tightly coupled in the time one was owned by the other. Every instance outside of `FnCtxt.inh` was from an `InferCtxt` created and dropped in the same function body.
This conflicts slightly with #30652, but there too it looks like the `FulfillmentContext` is from an `InferCtxt` that is created and dropped within the same function body (across one call to a module-private function).
That said, I heard that the PR that originally moved `FulfillmentContext` into `InferCtxt` was big, which leaves me concerned that I'm missing something.
r? @nikomatsakis
Ignores 82 rpass tests that use threads.
I took care to only ignore tests that call `thread::spawn`. Some tests, for example `issue-16597`, also do fail because of lack of threads support, but for other reasons.
With this PR, we're down to 49 failures.
r? @brson
This changes three ICEs to fatal errors.
I've grepped for `lang_item.*expect` and `\.expect.*lang` and didn't come up with any more. But, there could be more ICEs lurking.
I wasn't sure about a test because there already _is_ a cfail test for missing lang items, but it only checks one.
Relevant to (already closed) #31477#31480#31558.
cc @lilred
This fixes#31512 for me.
A bit of explanation: I want to have `check_block_post(&mut self, &Context, &Block)` and `check_crate_post(&mut self, &Context, &Crate)` methods in both early and late lint passes. Ideally we'd have _post methods for all operations that walk, but this'll do for now.
@Manishearth r?
