rustfmt libarena/lib.rs
Note: it's my very first pull request. I'm trying to do something very simple to see how it works here, even if it's a tiny change or maybe it's not correct (sorry if it is the case).
r? @nrc
macros: improve 1.0/2.0 interaction
This PR supports using unhygienic macros from hygienic macros without breaking the latter's hygiene.
```rust
// crate A:
#[macro_export]
macro_rules! m1 { () => {
f(); // unhygienic: this macro needs `f` in its environment
fn g() {} // (1) unhygienic: `g` is usable outside the macro definition
} }
// crate B:
#![feature(decl_macro)]
extern crate A;
use A::m1;
macro m2() {
fn f() {} // (2)
m1!(); // After this PR, `f()` in the expansion resolves to (2), not (3)
g(); // After this PR, this resolves to `fn g() {}` from the above expansion.
// Today, it is a resolution error.
}
fn test() {
fn f() {} // (3)
m2!(); // Today, `m2!()` can see (3) even though it should be hygienic.
fn g() {} // Today, this conflicts with `fn g() {}` from the expansion, even though it should be hygienic.
}
```
Once this PR lands, you can make an existing unhygienic macro hygienic by wrapping it in a hygienic macro. There is an [example](b766fa887d) of this in the tests.
r? @nrc
Add iterator method specialisations to Range*
Add specialised implementations of `max` for `Range`, and `last`, `min` and `max` for `RangeInclusive`, all of which lead to significant advantages in the generated assembly on x86.
Note that adding specialisations of `min` and `last` for `Range` led to no benefit, and adding `sum` for `Range` and `RangeInclusive` led to type inference issues (though this is possibly still worthwhile considering the performance gain).
This addresses some of the concerns in #39975.
There are some tests that need to be disabled on CloudABI specifically,
due to the fact that the shims cannot be built in combination with
unix::ext or windows::ext. Also improve the scoping of some imports to
suppress compiler warnings.
As discussed in #47268, libstd isn't ready to have certain functionality
disabled yet. Follow wasm's approach of adding no-op modules for all of
the features that we can't implement.
I've placed all of those shims in a shims/ subdirectory, so we (the
CloudABI folks) can experiment with removing them more easily. It also
ensures that the code that does work doesn't get polluted with lots of
useless boilerplate code.
Though CloudABI is strongly inspired by POSIX, its absence of features
that don't work well with capability-based sandboxing makes it different
enough that adding bits to sys/unix will make things a mess. This change
therefore adds CloudABI specific platform code under sys/cloudabi and
borrows parts from sys/unix that can be used without changes.
One of the goals of this implementation is to build as much as possible
directly on top of CloudABI's system call layer, as opposed to using the
C library. This is preferred, as the system call layer is supposed to be
stable, whereas the C library ABI technically is not. An advantage of
this approach is that it allows us to implement certain interfaces, such
as mutexes and condition variables more optimally. They can be lighter
than the ones provided by pthreads.
This change disables some modules that cannot realistically be
implemented right now. For example, libstd's pathname abstraction is not
designed with POSIX *at() (e.g., openat()) in mind. The *at() functions
are the only set of file system APIs available on CloudABI. There is no
global file system namespace, nor a process working directory.
Discussions on how to port these modules over are outside the scope of
this change.
Apart from this change, there are still some other minor fixups that
need to be made to platform independent code to make things build. These
will be sent out separately, so they can be reviewed more thoroughly.
These automatically generated Rust source files allow us to invoke
system calls within CloudABI processes. These will be used by libstd to
implement primitives for I/O, threading, etc.
These source files are normally part of the 'cloudabi' crate. In the
case of libstd, we'd better copy them into the source tree, as having
external dependencies in libstd is a bit messy. Original source files
can be found here:
https://github.com/NuxiNL/cloudabi/tree/master/rust
Replace uses of DepGraph.in_ignore with DepGraph.with_ignore
I currently plan to track tasks in thread local storage. Ignoring things in a closure ensures that the ignore tasks do not overlap the beginning or end of any other task. The TLS API will also use a closure to change a TLS value, so having the ignore task be a closure also helps there.
It also adds `assert_ignored` which is used before a `TyCtxt` is created. Instead of adding a new ignore task this simply ensures that we are in a context where reads are ignored.
r? @michaelwoerister
When gluing two tokens, the second of which is joint, the result should also be
joint.
This fixes an issue with joining three `Dot` tokens to make a `DotDotDot` - the
intermediate `DotDot` would not be joint and therefore we would not attempt to
glue the last `Dot` token, yielding `.. .` instead of `...`.
[incremental] Specialize encoding and decoding of Fingerprints
This saves the storage space used by about 32 bits per `Fingerprint`.
On average, this reduces the size of the `/target/{mode}/incremental`
folder by roughly 5% [Full details here](https://gist.github.com/wesleywiser/264076314794fbd6a4c110d7c1adc43e).
Fixes#45875
r? @michaelwoerister
Fix built-in indexing not being used where index type wasn't "obviously" usize
Fixes#33903Fixes#46095
This PR was made possible thanks to the generous help of @eddyb
Following the example of binary operators, builtin checking for indexing has been moved from the typecheck stage to a writeback stage, after type constraints have been resolved.
Deprecate [T]::rotate in favor of [T]::rotate_{left,right}.
Background
==========
Slices currently have an **unstable** [`rotate`] method which rotates
elements in the slice to the _left_ N positions. [Here][tracking] is the
tracking issue for this unstable feature.
```rust
let mut a = ['a', 'b' ,'c', 'd', 'e', 'f'];
a.rotate(2);
assert_eq!(a, ['c', 'd', 'e', 'f', 'a', 'b']);
```
Proposal
========
Deprecate the [`rotate`] method and introduce `rotate_left` and
`rotate_right` methods.
```rust
let mut a = ['a', 'b' ,'c', 'd', 'e', 'f'];
a.rotate_left(2);
assert_eq!(a, ['c', 'd', 'e', 'f', 'a', 'b']);
```
```rust
let mut a = ['a', 'b' ,'c', 'd', 'e', 'f'];
a.rotate_right(2);
assert_eq!(a, ['e', 'f', 'a', 'b', 'c', 'd']);
```
Justification
=============
I used this method today for my first time and (probably because I’m a
naive westerner who reads LTR) was surprised when the docs mentioned that
elements get rotated in a left-ward direction. I was in a situation
where I needed to shift elements in a right-ward direction and had to
context switch from the main problem I was working on and think how much
to rotate left in order to accomplish the right-ward rotation I needed.
Ruby’s `Array.rotate` shifts left-ward, Python’s `deque.rotate` shifts
right-ward. Both of their implementations allow passing negative numbers
to shift in the opposite direction respectively. The current `rotate`
implementation takes an unsigned integer argument which doesn't allow
the negative number behavior.
Introducing `rotate_left` and `rotate_right` would:
- remove ambiguity about direction (alleviating need to read docs 😉)
- make it easier for people who need to rotate right
[`rotate`]: https://doc.rust-lang.org/std/primitive.slice.html#method.rotate
[tracking]: https://github.com/rust-lang/rust/issues/41891
