In 95d904625b output was accidentally moved
from STDERR to STDOUT.
This commit also changes the order of debug output. Previously, it was:
```
/* id 22: … */ {
…
}
DEBUG:rustc::middle::dataflow:
```
Now, it is:
```
DEBUG:rustc::middle::dataflow: /* id 22: … */ {
…
}
```
Register LLVM passes with the correct LLVM pass manager.
LLVM was upgraded to a new version in this commit:
f9d4149c29
which was part of this pull request:
https://github.com/rust-lang/rust/issues/26025
Consider the following two lines from that commit:
f9d4149c29 (diff-a3b24dbe2ea7c1981f9ac79f9745f40aL462)f9d4149c29 (diff-a3b24dbe2ea7c1981f9ac79f9745f40aL469)
The purpose of these lines is to register LLVM passes. Prior to the that
commit, the passes being handled were assumed to be ModulePasses (a
specific type of LLVM pass) since they were being added to a ModulePass
manager. After that commit, both lines were refactored (presumably in an
attempt to DRY out the code), but the ModulePasses were changed to be
registered to a FunctionPass manager. This change resulted in
ModulePasses being run, but a Function object was being passed as a
parameter to the pass instead of a Module, which resulted in
segmentation faults.
In this commit, I changed relevant sections of the code to check the
type of the passes being added and register them to the appropriate pass
manager.
Closes https://github.com/rust-lang/rust/issues/31067
In 95d904625b output was accidentally moved
from STDERR to STDOUT.
This commit also changes the order of debug output. Previously, it was:
```
/* id 22: … */ {
…
}
DEBUG:rustc::middle::dataflow:
```
Now, it is:
```
DEBUG:rustc::middle::dataflow: /* id 22: … */ {
…
}
```
LLVM was upgraded to a new version in this commit:
f9d4149c29
which was part of this pull request:
https://github.com/rust-lang/rust/issues/26025
Consider the following two lines from that commit:
f9d4149c29 (diff-a3b24dbe2ea7c1981f9ac79f9745f40aL462)f9d4149c29 (diff-a3b24dbe2ea7c1981f9ac79f9745f40aL469)
The purpose of these lines is to register LLVM passes. Prior to the that
commit, the passes being handled were assumed to be ModulePasses (a
specific type of LLVM pass) since they were being added to a ModulePass
manager. After that commit, both lines were refactored (presumably in an
attempt to DRY out the code), but the ModulePasses were changed to be
registered to a FunctionPass manager. This change resulted in
ModulePasses being run, but a Function object was being passed as a
parameter to the pass instead of a Module, which resulted in
segmentation faults.
In this commit, I changed relevant sections of the code to check the
type of the passes being added and register them to the appropriate pass
manager.
Closes https://github.com/rust-lang/rust/issues/31067
Version of Clang in repository is 3.9
So, error is caused by
```
./configure --enable-dist-host-only --enable-clang
```
Then, I got
```
configure: error: bad CLANG version: 3.9.0 (http://llvm.org/git/clang.git 3d5d4c39659f11dfbe8e11c857cadf5c449b559b) (http://llvm.org/git/llvm.git, need >=3.0svn
```
I fixed this issue by appending 3.9* in the if sentence.
Thanks.
E0210 explains about orphan rules and suggests using a local type as a workaround. It wasn't obvious to me that I couldn't use a type alias, so I added a note.
I tried to add an inline `span_suggestion()` to the error as well, but since generics don't have their own span it becomes too fragile/complicated to work.
r? @steveklabnik
fixes#19477
Responding to [a thread of discussion on the Rust subreddit](https://www.reddit.com/r/rust/comments/3racik/mutable_lifetimes_are_too_long_when_matching_an/),
it was identified that the presence of the Entry API is not duly
publicised. This commit aims to add some reasonable examples of
common usages of this API to the main example secion of the `HashMap`
documentation.
This is part of issue #29348.
Documentation of `CStr::from_ptr` suggests using `str::from_utf8(slice.to_bytes()).unwrap()`
to obtain a `&str` but `CStr` has `CStr::to_str` that does exactly that.
(First PR, be nice :)
Fix type parameter default error to mention type and trait definitions
Introduced in PR #30724, needs to mention that type parameter defaults
are legal in trait and type definitions too.
Fix type parameter default error to mention type and trait definitions
Introduced in PR #30724, needs to mention that type parameter defaults
are legal in trait and type definitions too.
We currently nest `<a>` tags which is doubleplusungood. So, for example, `(u8, u8)` will show up
with the left paren linked to the tuple primitive page, and the right paren unlinked, which looks ugly.
The COPYRIGHT file should be updated to note that Rust no longer ships with AUTHORS.txt.
$ git log -1 -- AUTHORS.txt
commit 402749c539
Author: Brian Anderson <banderson@mozilla.com>
Date: Wed Dec 2 22:16:08 2015 +0000
Remove AUTHORS.txt and add-authors.sh
Keeping this file up to date requires hours of work every release,
even with the script. It is a fool's errand and we shall not do it
any longer.
When I read the book, the following sentence of the reference documentation helped me greatly to understand slices:
"Slices are a view into a block of memory represented as a pointer and a length."
In this commit, I tried to integrate the gist of that into the slice section inside of "primitive-types.md". I am not a native speaker, so feel very free to improve the wording.
r? @steveklabnik
Fixes#31106.
- [ ] I wasn't sure of the correct `#[stable(...)]` definition to use here. Happy to fix it if it's incorrect.
- [ ] `ParseError` is sort of an ephemeral non-error, but do let me know if the implementation of `error::Error` for it should return something more descriptive than "parse error".
Use cold functions for panic formatting Option::expect, Result::unwrap, expect
These methods are marked inline, but insert a big chunk of formatting
code, as well as other error path related code, such as
deallocating a std::io::Error if you have one.
We can explicitly separate out that code path into a function that is
never inline, since the panicking case should always be rare.
E0210 explains about orphan rules and suggests using a local type as a
workaround. It wasn't obvious to me that I couldn't use a type
alias, so I added a note.
