This snuck through my refactor.
Would it be worth the effort to have a test pass that attempts to lint the code for all targets, even if it's not feasible to actually build and test it?
The book in "hello-world" tells that there are configs for some programs and gives a link to main repo's src/etc. Actually, these configs moved to separate repos some days ago. This PR adds a markdown file with links and moves "hello-world" link about editors to point directly to this new file.
`pipe(2)`, under FreeBSD and OpenBSD return a bidirectionnal pipe. So
reading from the writer would block (waiting data) instead of returning
an error.
like for FreeBSD, disable the test for OpenBSD.
This is a patch for #22291.
PLEASE_BENCH=1 adds --bench to the arguments passed to the executable to be tested. At the moment, compiletest does not accept a --bench argument, because it is not needed for any test in src/test/, even the tests in src/test/bench do not use #[bench].
I have updated the makefile to only add the --bench flag for crate tests. I do not think that changing compiletest add --bench to the run arguments of all compile tests makes sense, because it would mess up tests which check command line arguments. Also the bench option can be added as comment in a compile test as well.
It is not totally clear if we should just use whitespace, or if the full
unicode word-breaking algorithm is more correct. If there is demand we
can reconsider this decision (and consider the precise algorithm to use
in detail).
cc #15628.
This includes everything necessary for promoting borrows of constant rvalues to `'static`.
That is, `&expr` will have the type `&'static T` if `const T: &'static T = &expr;` is valid.
There is a small exception, dereferences of raw pointers, as they misbehave.
They still "work" in constants as I didn't want to break legitimate uses (are there any?).
The qualification done here can be expanded to allow simple CTFE via `const fn`.
Nonetheless, as this commit demonstrates, the previous commits was a [breaking-change].
In practice, breakage is focused on functions of this form:
```rust
fn foo(..., object: Box<FnMut()>)
````
where `FnMut()` could be any trait object type. The older scheme defaulted objects in argument
position so that they were bounded by a fresh lifetime:
```rust
fn foo<'a>(..., object: Box<FnMut()+'a>)
```
This meant that the object could contain borrowed data. The newer
scheme defaults to a lifetime bound of `'static`:
```rust
fn foo(..., object: Box<FnMut()+'static>)
```
This means that the object cannot contain borrowed data. In some cases, the best fix
is to stop using `Box`:
```rust
fn foo(..., object: &mut FnMut())
```
but another option is to write an explicit annotation for the `'a`
lifetime that used to be implicit. Both fixes are demonstrated in
this commit.
Highlights:
* Adds an 'uninstall.sh' script to `/usr/local/lib/rustlib/uninstall.sh`, the path to which is printed during installation.
* Components can be deselected during install, like `install.sh --without=rust-docs`.
* Components can be listed with `install.sh --list-components`.
* Vastly reduces spew during install (but supporting a `--verbose` option).
Typicall install run looks like:
```
brian@brianX1:~/dev/multirust⟫ sudo ./install.sh
[sudo] password for brian:
install: creating uninstall script at /usr/local/lib/rustlib/uninstall.sh
install: installing component 'rustc'
install: installing component 'cargo'
install: installing component 'rust-docs'
Rust is ready to roll.
```
Needs to be merged right before corresponding PRs to cargo and rust-packaging.
Fixes https://github.com/rust-lang/rust/issues/21117
Fixes https://github.com/rust-lang/rust/issues/20283
