Point to immutable arg/fields when trying to use as &mut
Present the following output when trying to access an immutable borrow's
field as mutable:
```
error[E0389]: cannot borrow data mutably in a `&` reference
--> $DIR/issue-38147-1.rs:27:9
|
26 | fn f(&self) {
| ----- use `&mut self` here to make mutable
27 | f.s.push('x');
| ^^^ assignment into an immutable reference
```
And the following when trying to access an immutable struct field as mutable:
```
error: cannot borrow immutable borrowed content `*self.s` as mutable
--> $DIR/issue-38147-3.rs:17:9
|
12 | s: &'a String
| ------------- use `&'a mut String` here to make mutable
...|
16 | fn f(&self) {
| ----- use `&mut self` here to make mutable
17 | self.s.push('x');
| ^^^^^^ cannot borrow as mutable
```
Fixes#38147.
Apparently LLVMArbitraryPrecisionInteger demands integers to be in low-endian 64-bytes, rather than
host-endian 64-bytes. This is weird, and obviously, not documented. Also, fixed now. And rustc now
works a teeny bit more on big endians.
Bounds parsing refactoring 2
See https://github.com/rust-lang/rust/pull/37511 for previous discussion.
cc @matklad
Relaxed parsing rules:
- zero bounds after `:` are allowed in all contexts.
- zero predicates are allowed after `where`.
- trailing separator `,` is allowed after predicates in `where` clauses not followed by `{`.
Other parsing rules:
- trailing separator `+` is still allowed in all bound lists.
Code is also cleaned up and tests added.
I haven't touched parsing of trait object types yet, I'll do it later.
These give so many incorrect suggestions that having them is
detrimental to the user experience. The compiler should not be
suggesting changes to the code that are wrong - it is infuriating: not
only is the compiler telling you that _you don't understand_ borrowing,
_the compiler itself_ appears to not understand borrowing. It does not
inspire confidence.
LLVM Core C bindings provide this function for all the versions back to what we support (3.7), and
helps to avoid this unnecessary builder->function transition every time. Also a negative diff.
Point to immutable borrow arguments and fields when trying to use them as
mutable borrows. Add label to primary span on "cannot borrow as mutable"
errors.
Present the following output when trying to access an immutable borrow's
field as mutable:
```
error[E0389]: cannot borrow data mutably in a `&` reference
--> $DIR/issue-38147-1.rs:27:9
|
26 | fn f(&self) {
| ----- use `&mut self` here to make mutable
27 | f.s.push('x');
| ^^^ assignment into an immutable reference
```
And the following when trying to access an immutable struct field as mutable:
```
error: cannot borrow immutable borrowed content `*self.s` as mutable
--> $DIR/issue-38147-3.rs:17:9
|
12 | s: &'a String
| ------------- use `&'a mut String` here to make mutable
...|
16 | fn f(&self) {
| ----- use `&mut self` here to make mutable
17 | self.s.push('x');
| ^^^^^^ cannot borrow as mutable
```
This comes up when using `-Zunstable-options --unpretty=mir`.
Previously, rustc would ICE due to an unwrap later in this function
(after `as_local_node_id`). Instead, we should just ignore items from
other crates when pretty-printing MIR.
I've seen these take up quite a bit of log space and I have the sneaking
suspicion that they're just making our test suite take longer (sometimes timing
out on 32-bit OSX now). In any case the backtraces haven't proven too useful,
unfortunately.
Rename tcx.map to the far more descriptive tcx.hir.
Also a bit more renaming because `ast_map` and `'ast` were still used with HIR.
Main motivation is to "free up" `tcx.map`, or rather, `tcx.maps`, to consolidate `ty::maps` there.
r? @nikomatsakis
For every method, the first sentence should consisely explain what it does,
not how. This sentence usually starts with a verb.
It's really weird for `sort` to be explained in terms of another function,
namely `sort_by`. There's no need for that because it's obvious how `sort`
sorts elements: there is `T: Ord`.
If `sort_by_key` does not have to explicitly state how it's implemented,
then `sort` doesn't either.
process trait/impl items directly from the visitor callback
The current setup processes impl/trait items while visiting
the impl/trait. This means we basically have this setup:
<Lots> -> TypeckItemBody(Impl) -> Tables(ImplItem{0,1,2,3})
But this was largely an artifact of the older code. By moving the
processing of items into method dedicated for their use, we produce this
setup:
<Little> -> TypeckItemBody(ImplItem0) -> Tables(ImplItem0)
...
<Little> -> TypeckItemBody(ImplItem3) -> Tables(ImplItem3)
r? @michaelwoerister
Also, we might consider removing the `TypeckItemBody` node altogether and just using `Tables` as the task. `Tables` is its primary output, I imagine? That would reduce size of dep-graph somewhat.
cc @eddyb -- perhaps this pattern applies elsewhere?
This commit applies the stabilization/deprecations of the 1.16.0 release, as
tracked by the rust-lang/rust issue tracker and the final-comment-period tag.
The following APIs were stabilized:
* `VecDeque::truncate`
* `VecDeque::resize`
* `String::insert_str`
* `Duration::checked_{add,sub,div,mul}`
* `str::replacen`
* `SocketAddr::is_ipv{4,6}`
* `IpAddr::is_ipv{4,6}`
* `str::repeat`
* `Vec::dedup_by`
* `Vec::dedup_by_key`
* `Result::unwrap_or_default`
* `<*const T>::wrapping_offset`
* `<*mut T>::wrapping_offset`
* `CommandExt::creation_flags` (on Windows)
* `File::set_permissions`
* `String::split_off`
The following APIs were deprecated
* `EnumSet` - replaced with other ecosystem abstractions, long since unstable
Closes#27788Closes#35553Closes#35774Closes#36436Closes#36949Closes#37079Closes#37087Closes#37516Closes#37827Closes#37916Closes#37966Closes#38080
Partially implement RFC 1647 (`Self` in impl headers)
The name resolution part is easy, but the typeck part contains an unexpected problem.
It turns out that `Self` type *depends* on bounds and `where` clauses, so we need to convert them first to determine what the `Self` type is! If bounds/`where` clauses can refer to `Self` then we have a cyclic dependency.
This is required to support impls like this:
```
// Found in libcollections
impl<I: IntoIterator> SpecExtend<I> for LinkedList<I::Item> { .... }
^^^^^ associated type `Item` is found using information from bounds
```
I'm not yet sure how to resolve this issue.
One possible solution (that feels hacky) is to make two passes over generics - first collect predicates ignoring everything involving `Self`, then determine `Self`, then collect predicates again without ignoring anything. (Some kind of lazy on-demand checking or something looks like a proper solution.)
This patch in its current state doesn't solve the problem with `Self` in bounds, so the only observable things it does is improving error messages and supporting `impl Trait<Self> for Type {}`.
There's also a question about feature gating. It's non-trivial to *detect* "newly resolved" `Self`s to feature gate them, but it's simple to *enable* the new resolution behavior when the feature gate is already specified. Alternatively this can be considered a bug fix and merged without a feature gate.
cc https://github.com/rust-lang/rust/issues/38864
r? @nikomatsakis
cc @eddyb
Whitespace ignoring diff https://github.com/rust-lang/rust/pull/38920/files?w=1
The current setup processes impl/trait items while visiting
the impl/trait. This means we basically have this setup:
<Lots> -> TypeckItemBody(Impl) -> Tables(ImplItem{0,1,2,3})
But this was largely an artifact of the older code. By moving the
processing of items into method dedicated for their use, we produce this
setup:
<Little> -> TypeckItemBody(ImplItem0) -> Tables(ImplItem0)
...
<Little> -> TypeckItemBody(ImplItem3) -> Tables(ImplItem3)
Add std::process::Command::envs()
`Command::envs()` adds a vector of key-value pairs to the child
process environment all at once. Suggested in #38526.
This is not fully baked and frankly I'm not sure it even _works_, but I need some help finishing it up, and this is the simplest way to show you what I've got. The problems I know exist and don't know how to solve, from most to least important, are:
* [ ] I don't know if the type signature of the new function is correct.
* [x] The new test might not be getting run. I didn't see it go by in the output of `x.py test src/libstd --stage 1`.
* [x] The tidy check says ``process.rs:402: different `since` than before`` which I don't know what it means.
r? @brson
Previously we only uploaded tarballs, but this modifies Travis/AppVeyor to
upload everything. We shouldn't have anything else in there to worry about and
otherwise we need to be sure to pick up pkg/msi/exe installers.
This commit adds a new tool, `build-manifest`, which is used to generate a
distribution manifest of all produced artifacts. This tool is intended to
replace the `build-rust-manifest.py` script that's currently located on the
buildmaster. The intention is that we'll have a builder which periodically:
* Downloads all artifacts for a commit
* Runs `./x.py dist hash-and-sign`. This will generate `sha256` and `asc` files
as well as TOML manifests.
* Upload all generated hashes and manifests to the directory the artifacts came
from.
* Upload *all* artifacts (tarballs and hashes and manifests) to an archived
location.
* If necessary, upload all artifacts to the main location.
This script is intended to just be the second step here where orchestrating
uploads and such will all happen externally from the build system itself.
Update Fuchsia support for std::process.
- Adds support for try_wait.
- Miscellaneous updates to keep up with Magenta changes.
I'll begin `sys/fuchsia` soon, just been bogged down with my actual job lately (I'm not on the Fuchsia team).
