- Graphemes and GraphemeIndices structs implement iterators over
grapheme clusters analogous to the Chars and CharOffsets for chars in
a string. Iterator and DoubleEndedIterator are available for both.
- tidied up the exports for libunicode. crate root exports are now moved
into more appropriate module locations:
- UnicodeStrSlice, Words, Graphemes, GraphemeIndices are in str module
- UnicodeChar exported from char instead of crate root
- canonical_combining_class is exported from str rather than crate root
Since libunicode's exports have changed, programs that previously relied
on the old export locations will need to change their `use` statements
to reflect the new ones. See above for more information on where the new
exports live.
closes#7043
[breaking-change]
Currently when a read-only file has unlink() invoked on it on windows, the call
will fail. On unix, however, the call will succeed. In order to have a more
consistent behavior across platforms, this error is recognized on windows and
the file is changed to read-write before removal is attempted.
Currently when a read-only file has unlink() invoked on it on windows, the call
will fail. On unix, however, the call will succeed. In order to have a more
consistent behavior across platforms, this error is recognized on windows and
the file is changed to read-write before removal is attempted.
Not sure how to test this correctly I assume the current tests pass now because of the crate boundaries [and that this is fallout from private by default]?
In order to have the spawning semantics be the same for unix/windows, the
child's PATH environment variable needs to be searched rather than the parent's
environment variable.
If the child is inheriting the parent's PATH, then no action need be taken as
windows will do the heavy lifting. If the child specifies its own PATH, then it
is searched beforehand for the target program and the result is favored if a hit
is found.
cc #15149, but does not close the issue because libgreen still needs to be
updated.
In order to have the spawning semantics be the same for unix/windows, the
child's PATH environment variable needs to be searched rather than the parent's
environment variable.
If the child is inheriting the parent's PATH, then no action need be taken as
windows will do the heavy lifting. If the child specifies its own PATH, then it
is searched beforehand for the target program and the result is favored if a hit
is found.
cc #15149, but does not close the issue because libgreen still needs to be
updated.
This PR is the outcome of the library stabilization meeting for the
`liballoc::owned` and `libcore::cell` modules.
Aside from the stability attributes, there are a few breaking changes:
* The `owned` modules is now named `boxed`, to better represent its
contents. (`box` was unavailable, since it's a keyword.) This will
help avoid the misconception that `Box` plays a special role wrt
ownership.
* The `AnyOwnExt` extension trait is renamed to `BoxAny`, and its `move`
method is renamed to `downcast`, in both cases to improve clarity.
* The recently-added `AnySendOwnExt` extension trait is removed; it was
not being used and is unnecessary.
[breaking-change]
This PR is the outcome of the library stabilization meeting for the
`liballoc::owned` and `libcore::cell` modules.
Aside from the stability attributes, there are a few breaking changes:
* The `owned` modules is now named `boxed`, to better represent its
contents. (`box` was unavailable, since it's a keyword.) This will
help avoid the misconception that `Box` plays a special role wrt
ownership.
* The `AnyOwnExt` extension trait is renamed to `BoxAny`, and its `move`
method is renamed to `downcast`, in both cases to improve clarity.
* The recently-added `AnySendOwnExt` extension trait is removed; it was
not being used and is unnecessary.
[breaking-change]
This patch adds support for macros in method position. It follows roughly the template for Item macros, where an outer `Method` wrapper contains a `Method_` enum which can either be a macro invocation or a standard macro definition.
One note; adding support for macros that expand into multiple methods is not included here, but should be a simple parser change, since this patch updates the type of fold_macro to return a smallvector of methods.
For reviewers, please pay special attention to the parser changes; these are the ones I'm most concerned about.
Because of the small change to the interface of fold_method, this is a ...
[breaking change]
This change propagates to many locations, but because of the
Macro Exterminator (or, more properly, the invariant that it
protects), macro invocations can't occur downstream of expansion.
This means that in librustc and librustdoc, extracting the
desired field can simply assume that it can't be a macro
invocation. Functions in ast_util abstract over this check.
The new iterator takes a function and produces an infinite stream
of results of repeated applications of the function, starting from
the provided seed value.
Implementation by Kevin Ballard.
The function returns an Unfold iterator producing an infinite stream
of results of repeated applications of the function, starting from
the provided seed value.
