Auto merge of #28603 - steveklabnik:small_config_fix, r=alexcrichton
We don't actually probe for javac in all circumstances, so if you have
javac installed, but don't have antlr4 installed, and you're on Mac OS
X, then you'll get a message that javac is missing, even though that's
wrong.
To fix this, let's just be a bit more generic in the message, so that
it's the same no matter what part of the lexer tests you're missing.
cc
https://www.reddit.com/r/rust/comments/3m199d/running_make_check_on_the_source_code_says_javac/
Steve Klabnik [Wed, 23 Sep 2015 15:43:49 +0000 (11:43 -0400)]
Make lexer tooling message more generic
We don't actually probe for javac in all circumstances, so if you have
javac installed, but don't have antlr4 installed, and you're on Mac OS
X, then you'll get a message that javac is missing, even though that's
wrong.
To fix this, let's just be a bit more generic in the message, so that
it's the same no matter what part of the lexer tests you're missing.
cc
https://www.reddit.com/r/rust/comments/3m199d/running_make_check_on_the_source_code_says_javac/
Auto merge of #28585 - ranma42:simpler-panic, r=alexcrichton
This is part of some cleanup I did while investigating #28129.
This also ensures that `on_panic` is run even if the user has registered too many callbacks.
Part of https://github.com/rust-lang/rust/issues/6993
This patch replaces `Ident`s with `Name`s in data structures of HIR and updates the dependent crates to compile and pass `make check`.
Some HIR structures still use `Ident`s, namely `PathSegment`, `PatIdent`, `ExprWhile`, `ExprLoop`, `ExprBreak` and `ExprAgain`, they need them for resolve (but `PathSegment` is special, see https://github.com/rust-lang/rust/issues/6993#issuecomment-141256292).
Auto merge of #28504 - Eljay:fix-trait-privacy, r=nrc
Fixes #16264 / #18241.
As far as I can tell, it should be impossible for a trait to be inaccessible if it's in scope, so this check is unnecessary. Are there any cases where this check is actually needed?
equals `*mut Fn(&usize)` which seems to be caused by `higher_ranked_sub()` allowing region variables to escape the comparison. This prevents inference from working properly with stuff like `Rc<Fn(&T)>`.
Auto merge of #28543 - gandro:netbsd, r=alexcrichton
These changes introduce the ability to cross-compile working binaries for NetBSD/amd64. Previous support added in PR #26682 shared all its code with the OpenBSD implementation, and was therefore never functional (e.g. linking against non-existing symbols and using wrong type definitions). Nonetheless, the previous patches were a great starting point and made my work significantly easier. :smiley:
Because there are no stage0 snapshots for NetBSD (yet), I used a cross-compiler for NetBSD 7.0 RC3 and only tested some toy programs (threading and channels, stack guards, a small TCP/IP echo server and some other platform dependent bits). If someone could point me to documentation on how to generate a stage0 snapshot from a cross-compiler I'm happy to run the full test suite.
A few other notes regarding Rust on NetBSD/amd64:
- To preserve binary compatibility, NetBSD introduces new symbols for system call wrappers on breaking ABI changes and keeps the old (legacy) symbols around, see [this documentation](https://www.netbsd.org/docs/internals/en/chap-processes.html#syscalls_master) for some details. I went ahead and modified the `libc` and `std` crate to use the current (renamed) symbols instead of the legacy ones where I found them, but I might have missed some. Notably using the `sigaction` symbol (deprecated in 1998) instead of `__sigaction14` even triggers SIGSYS (bad syscall) on my amd64 setup. I also changed the type definitions to use the most recent version.
- NetBSD's gdb doesn't really support position independent executables, so you might want to turn that off for debugging, see [NetBSD Problem Report #48250](https://gnats.netbsd.org/48250).
- For binaries invoked using a relative path, NetBSD supports `$ORIGIN` only for short `rpath`s (~64 chars or so, I'm told). If running an executable fails with `execname not specified in AUX vector: No such file or directory`, consider invoking the binary using its full absolute path.
Andrea Canciani [Tue, 22 Sep 2015 16:51:04 +0000 (18:51 +0200)]
Remove unwind::register
The `register` function is unstable and it is not used anymore, hence
it can be removed (together with the now-unused `Callback` type and
`static` variables).
Use Names in the remaining HIR structures with exception of...
PathSegment, PatIdent, ExprWhile, ExprLoop, ExprBreak and ExprAgain - they need Idents for resolve
Auto merge of #28578 - gandro:nodefaultlibs, r=alexcrichton
This patch basically adds a target option for omitting the `-nodefaultlibs` flag when invoking the linker. I am not sure if this is the correct or only way to approach this problem, so any feedback is welcome.
Motivation: I'm currently working on a Rust target specification for the [rumprun](/rumpkernel/rumprun) unikernel. rumprun is based on rump kernels and uses NetBSDs libc and drivers to provide a POSIXy environment. It provides its own linker wrapper that generates binaries which can be "baked" into a unikernel after configuration. Using `-nodefaultlibs` on the rumprun linker will prevent it from selecting the search paths for the rumprun libraries. My current target implementation for rumprun is here: gandro/rust@295744b2ee2378f41a20d4b498b8f1991a75e93c
Currently, only a target that `is_like_windows` will omit the `-nodefaultlibs` flag, but since rumprun is not like Windows otherwise, I think a separate flag makes more sense. This might be a breaking change for target specifications that have the `is_like_windows` option set to true. Such targets need to set `no_default_libraries` to false in order to restore the old behavior.
Sebastian Wicki [Mon, 21 Sep 2015 17:02:46 +0000 (19:02 +0200)]
Add `no_default_libraries` target linker option
If set to false, `-nodefaultlibs` is not passed to the linker. This
was the default behavior on Windows, but it should be configurable
per target.
This is a [breaking-change] for target specifications that have
the `is_like_windows` option set to true. Such targets need to
set `no_default_libraries` to false in order to restore the old
behavior.
Auto merge of #28562 - llogiq:shootout, r=alexcrichton
Since 1.3.0 the BufWriter has seen tremendous speedups. So when I use it in the shootout benchmarks, I see some nice speedup (which up to 1.2.0 was nixed by the pessimizations during initialization).
Auto merge of #28531 - whitequark:patch-1, r=Gankro
With -O2, LLVM's inliner can remove this code, but this does not happen
with -O1 and lower. As a result, dropping Vec<u8> was linear with length,
resulting in abysmal performance for large buffers.
Auto merge of #28539 - rkruppe:shuffle-num-internals, r=alexcrichton
Move private bignum module to core::num, because it is not only used in flt2dec.
Extract private 80-bit soft-float into new core::num module for the same reason.
Auto merge of #28429 - wesleywiser:split_up_lints, r=alexcrichton
This breaks out some of the lints defined in `librustc_lint/builtin.rs` into two new modules: `unused` for the `UNUSED_*` lints and `bad_style` for the various style related lints as suggested in #22206. `builtin.rs` could probably get broken up more but this is a start.
Auto merge of #28501 - semarie:stdcpp-path, r=alexcrichton
By default, the linker in use under OpenBSD is the linker of base, which
don't include /usr/local/lib where libstdc++ of gcc-4.9 lives. We need
to add this directory to linker-path-search (using -L).
Search the path of libstdc++.a, which is a known name (libstdc++.so has
SO_VERSION) in the same directory.
r? @alexcrichton
this commit needs #28495 to be commited first. It should be the last piece for building rustc under OpenBSD from scratch.
Sébastien Marie [Fri, 18 Sep 2015 21:02:05 +0000 (23:02 +0200)]
Pass libstdc++.so path to linker under OpenBSD
By default, the linker in use under OpenBSD is the linker of base, which
don't include /usr/local/lib where libstdc++ of gcc-4.9 lives. We need
to add this directory to linker-path-search (using -L).
Search the path of libstdc++.a, which is a known name (libstdc++.so has
SO_VERSION) in the same directory.
Robin Kruppe [Sun, 20 Sep 2015 16:34:33 +0000 (18:34 +0200)]
Reorganize core::num internals
Move private bignum module to core::num, because it is not only used in flt2dec.
Extract private 80-bit soft-float into new core::num module for the same reason.
Do not drop_in_place elements of Vec<T> if T doesn't need dropping
With -O2, LLVM's inliner can remove this code, but this does not happen
with -O1 and lower. As a result, dropping Vec<u8> was linear with length,
resulting in abysmal performance for large buffers.
Auto merge of #28519 - wthrowe:fixup-28321, r=alexcrichton
I assume the expected error changed during the development of pull
request #28321 and that wasn't noticed because the test was
accidentally not running.
William Throwe [Sat, 19 Sep 2015 16:49:56 +0000 (12:49 -0400)]
Move test to the right directory and make it pass
I assume the expected error changed during the development of pull
request #28321 and that wasn't noticed because the test was
accidentally not running.
Auto merge of #28497 - apasel422:issue-28493, r=Gankro
When both the key and value types were zero-sized, `BTreeMap` previously
called `heap::allocate` with `size == 0` for leaf nodes, which is
undefined behavior, and jemalloc would attempt to read invalid memory,
crashing the process.
This avoids undefined behavior by allocating enough space to store one
edge in leaf nodes that would otherwise have `size == 0`. Although this
uses extra memory, maps with zero-sized key types that have sensible
implementations of the ordering traits can only contain a single
key-value pair (and therefore only a single leaf node), and maps with
key and value types that are both zero-sized have few uses, if any.
Furthermore, this is a temporary fix that will likely be unnecessary
once the `BTreeMap` implementation is rewritten to use parent pointers.
projects / rust.git / log