Skip to content

Rollup of 15 pull requests #21530

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 172 commits into from
Jan 23, 2015
Merged

Rollup of 15 pull requests #21530

merged 172 commits into from
Jan 23, 2015

Conversation

KOMON and others added 30 commits December 16, 2014 00:43

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
* Include an illustration of a function that accepts two closures.
This way installer can work fully in offline mode.

Put pre-downloaded files
(rust-nightly-x86_64-unknown-linux-gnu.tar.gz and
 rust-nightly-x86_64-unknown-linux-gnu.tar.gz.sha256)
into the $HOME/.rustup/YYYY-MM-DD directory
as it would be done by script itself.

Specify --save and --date=YYYY-MM-DD when running.
Files will be picked up and used to install in offline mode.
Previous wording wasn’t clear about its actual behaviour. It could be
interpreted as answering either:

* Can current thread panic?
* Is current thread unwinding because of panic?
File cannot be written, for example, if directory does not exist.

Before this commit:

```
% rustc -o nonexistent/program program.rs
error: could not write output: No such file or directory
```

With this commit:

```
% rustc -o nonexistent/program program.rs
error: could not write output to nonexistent/program.0.o: No such file or directory
```

This is useful when full rust command is not displayed, or when last
error is preceded by thousands of warnings.
This is wanted by external tooling that uses rustdoc. There are likely
some bugs when actually generating HTML output (which may expect to be
able to read the source) but all I need for now is the cleaned crate and
analysis.
There are two limitations to the macro that this addresses:
1. the expected type is not propagated, coercions don't trigger
2. references inside element expressions don't outlive the `Vec`

Both of these limitations are caused by the block in the
macro expansion, previously needed to trigger a coercion
from `Box<[T; N]>` to `Box<[T]>`, now possible with UFCS.
Fixes rust-lang#20943

Signed-off-by: Peter Atashian <retep998@gmail.com>
bors and others added 20 commits January 22, 2015 12:09
* Include an illustration of a function that accepts two closures.
When we moved over to the book, we lost this.
…kler

When we moved over to the book, we lost this.
…huonw

Fixes rust-lang#6444

I need some help with the macro docs here, as I couldn't figure it out. @kmcallister @eddyb  or someone else?
Not sure on what *exactly* should be said here, but I think this is the most important bit. This PR also establishes conventions for describing performance minimally.

I suggest to describe preformance for individual methods we use a `# Performance` heading. Not sure if we should have 

```
# Performance: O(1)
details details
```
or

```
# Performance:
O(1)
details details
```

Since I think most methods don't need discussion, the former seems more resonable. But it's kind of weird to have info "in" the heading.

r? @steveklabnik
…bnik

Previous wording wasn’t clear about its actual behaviour. It could be
interpreted as answering either:

* Can current thread panic?
* Is current thread unwinding because of panic?

r? @steveklabnik
Updated incorrect error messages, and removed explicit return statements from example code.
Compiling won't produce an executable just yet because (as stated in the next
paragraph) there are errors. By removing this sentance, the reader won't get
confused when they expect a successful compile i.e. if they don't read ahead one
paragraph, they are going to be checking their code and wondering why it's not
compiling.
…r=alexcrichton

This should fix issue rust-lang#20797 (but I don't want to close it automatically).
As the actual fix is very small this would be a perfect candidate for a rollup.
Make compiletest set an environment variable so that on Windows 32-bit test executables containing certain substrings (e.g. 'install', 'setup', 'update', 'patch') are not blocked by UAC's Installer Detection Technology.
When I wrote this code, my janky shim to verify the constants didn't
work as intended.

This fixes everything I've run into since merge, which is hopefully
everything.
Lifetime elision documentation was reference a previously existing function
that doesn't exist. After talking with Steve Klabnik, I confirmed the correct
function to be referenced and updated documentation accordingly.
@rust-highfive
Copy link
Contributor

r? @pcwalton

(rust_highfive has picked a reviewer for you, use r? to override)

@steveklabnik
Copy link
Member Author

@bors: r+ 9fb672b p=1

@bors
Copy link
Collaborator

bors commented Jan 23, 2015

⌛ Testing commit 9fb672b with merge 4874ca3...

bors added a commit that referenced this pull request Jan 23, 2015
@bors bors merged commit 9fb672b into rust-lang:master Jan 23, 2015
@Centril Centril added the rollup A PR which is a rollup label Oct 2, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
rollup A PR which is a rollup
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet