bors [Tue, 26 Jan 2016 00:42:08 +0000 (00:42 +0000)]
Auto merge of #31065 - nrc:ident-correct, r=pnkfelix
This PR adds some minor error correction to the parser - if there is a missing ident, we recover and carry on. It also makes compilation more robust so that non-fatal errors (which is still most of them, unfortunately) in parsing do not cause us to abort compilation. The effect is that a program with a missing or incorrect ident can get all the way to type checking.
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.
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.
bors [Sun, 24 Jan 2016 18:09:51 +0000 (18:09 +0000)]
Auto merge of #31162 - mopp:fix_configure_for_new_clang, r=alexcrichton
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.
Steve Klabnik [Sat, 23 Jan 2016 14:38:44 +0000 (09:38 -0500)]
Rollup merge of #31130 - marcbowes:master, r=nrc
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.
Steve Klabnik [Sat, 23 Jan 2016 14:38:42 +0000 (09:38 -0500)]
Rollup merge of #31054 - steveklabnik:a11y, r=alexcrichton
I've been interested in the accessibility of Rustdoc's output, but never did anything about it. Today, I ran a tool, and it suggested adjusting some colors.
Here's some screen shots. Before:
Steve Klabnik [Sat, 23 Jan 2016 14:38:42 +0000 (09:38 -0500)]
Rollup merge of #31045 - Manishearth:diag-prim-shadow, r=steveklabnik
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.
Steve Klabnik [Sat, 23 Jan 2016 14:38:41 +0000 (09:38 -0500)]
Rollup merge of #31035 - nathankleyn:improve-visibility-of-entry-api, r=steveklabnik
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.
Steve Klabnik [Sat, 23 Jan 2016 14:38:41 +0000 (09:38 -0500)]
Rollup merge of #31019 - andreabedini:patch-1, r=alexcrichton
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.
bors [Sat, 23 Jan 2016 11:38:43 +0000 (11:38 +0000)]
Auto merge of #31121 - Manishearth:prim-link, r=alexcrichton
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.
bors [Sat, 23 Jan 2016 07:44:17 +0000 (07:44 +0000)]
Auto merge of #30807 - kolloch:patch-1, r=steveklabnik
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.
bors [Sat, 23 Jan 2016 04:04:26 +0000 (04:04 +0000)]
Auto merge of #31124 - dirk:dirk/display-and-error-impls-for-string-parse-error, r=alexcrichton
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".
bors [Sat, 23 Jan 2016 00:33:23 +0000 (00:33 +0000)]
Auto merge of #31116 - bluss:expect-out-cold, r=alexcrichton
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.
Marc Bowes [Fri, 22 Jan 2016 20:20:36 +0000 (22:20 +0200)]
E0210: Add a warning about type aliases
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.
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.
bors [Fri, 22 Jan 2016 17:09:37 +0000 (17:09 +0000)]
Auto merge of #31087 - nikomatsakis:incr-comp-fulfillment-cache, r=arielb1
This is a fix for #30741. It simplifies dep-graph tracking for trait matching. I was experimenting with having a greater resolution here, but decided to pare back to just have one dep node for "trait resolutions on trait `Foo`", which means that adding an impl to the trait `Foo` will invalidate all fns that had to do any trait matching at all on `Foo`. This seems like a reasonable starting place.
Independently, I realized I had neglected to record a dependency from trans on typeck -- this is obviously needed, since trans consumes a bunch of data structures that typeck produces (but which are not currently individually tracked) -- and because trans assumes that typeck has been done. Eventually those are going to go away and be replaced with MIR, which will be tracked, so this edge would presumably be derived automatically then, but it's an obvious enough thing to want for now.
r? @arielb1
cc @michaelwoerister -- this might indirectly fix the problem you observed with the trans cache, though it'd be nice to try and craft an independent test case for that.
bors [Fri, 22 Jan 2016 09:46:17 +0000 (09:46 +0000)]
Auto merge of #31074 - gmbonnet:stage0-libdir, r=alexcrichton
This fixes #27254.
On a 64-bit Linux machine, for example, `configure --libdir=/usr/local/lib64` was creating both `x86_64-unknown-linux-gnu/stage0/lib/rustlib` and `x86_64-unknown-linux-gnu/stage0/lib64/rustlib`. Crates from the stage0 snapshot, like `libcore`, are extracted to `x86_64-unknown-linux-gnu/stage0/lib/rustlib`, but the stage0 compiler was attempting to find them in `x86_64-unknown-linux-gnu/stage0/lib64/rustlib`, which has the highest priority on a 64-bit system.
The issue can be fixed by creating only `x86_64-unknown-linux-gnu/stage0/lib/rustlib`, since this is the only rustlib directory needed for stage0 anyways.
bors [Fri, 22 Jan 2016 00:31:29 +0000 (00:31 +0000)]
Auto merge of #30944 - fhahn:issue-29789-use-constant2, r=nagisa
This PR for #29789 uses `rustc::repr::mir::Constant` in `ExprKind::Repeat`, which seems to fit quite nicely. Is there a reason for not re-using that type?
bors [Thu, 21 Jan 2016 22:41:37 +0000 (22:41 +0000)]
Auto merge of #30882 - petrochenkov:varnamesp, r=nrc
Tuple and unit variants from other crates weren't put into type namespace.
Now variant namespacing is aligned with struct namespacing and is not affected by the variant's crate of origin (struct -> type, tuple/unit -> type/value).
Additionally, struct variants from other crates are put into value namespace (struct variants from local crate were already in it). This is not a necessity, but a future proofing measure.
This fix can result in some new shadowing errors in cross-crate scenarios, crater reports [three regressions](https://github.com/rust-lang/rust/pull/30882#issuecomment-172369883).
[breaking-change]
Niko Matsakis [Wed, 20 Jan 2016 21:56:29 +0000 (16:56 -0500)]
Revamp the fulfillment cache tracking to only cache trait-refs, which
was the major use-case, and to update the dep-graph. Other kinds of
predicates are now excluded from the cache because there is no easy way
to make a good dep-graph node for them, and because they are not
believed to be that useful. :)
Fixes #30741. (However, the test still gives wrong result for trans,
for an independent reason which is fixed in the next commit.)
projects / rust.git / log