Auto merge of #28632 - alexcrichton:update-match-indices, r=Kimundi
This commit updates the `MatchIndices` and `RMatchIndices` iterators to follow
the same pattern as the `chars` and `char_indices` iterators. The `matches`
iterator currently yield `&str` elements, so the `MatchIndices` iterator now
yields the index of the match as well as the `&str` that matched (instead of
start/end indexes).
Auto merge of #28593 - gandro:rumprun, r=alexcrichton
This adds a new target, `x86_64-rumprun-netbsd`, and related changes to `std`.
Rumprun is a unikernel platform that provides a POSIX-y interface. For the most part, rumprun uses NetBSD's libc and drivers, therefore `target_os` is `netbsd`. However, being a unikernel, rumprun does not support process management, signals or virtual memory, so related functions might fail at runtime. For this reason, stack guards are disabled in `std`.
To support conditional compilation, `target_env` is set to `rumprun`. Maybe `target_vendor` would be technically more fitting, but it doesn't seem to be worth the hassle.
Code for rumprun is always cross-compiled, it uses always static linking and needs a custom linker. The target makes use of the newly introduced `no_default_libs` flag, as the rumprun linker will otherwise not use the correct search path.
This PR removes random remaining `Ident`s outside of libsyntax and performs general cleanup
In particular, interfaces of `Name` and `Ident` are tidied up, `Name`s and `Ident`s being small `Copy` aggregates are always passed to functions by value, and `Ident`s are never used as keys in maps, because `Ident` comparisons are tricky.
Although this PR closes https://github.com/rust-lang/rust/issues/6993 there's still work related to it:
- `Name` can be made `NonZero` to compress numerous `Option<Name>`s and `Option<Ident>`s but it requires const unsafe functions.
- Implementation of `PartialEq` on `Ident` should be eliminated and replaced with explicit hygienic, non-hygienic or member-wise comparisons.
- Finally, large parts of AST can potentially be converted to `Name`s in the same way as HIR to clearly separate identifiers used in hygienic and non-hygienic contexts.
Sebastian Wicki [Mon, 21 Sep 2015 17:16:24 +0000 (19:16 +0200)]
Add support for the rumprun unikernel
For most parts, rumprun currently looks like NetBSD, as they share the same
libc and drivers. However, being a unikernel, rumprun does not support
process management, signals or virtual memory, so related functions
might fail at runtime. Stack guards are disabled exactly for this reason.
Code for rumprun is always cross-compiled, it uses always static
linking and needs a custom linker.
Auto merge of #28631 - ranma42:robust-panic, r=alexcrichton
This is mainly to avoid infinite recursion and make debugging more convenient in the anomalous case in which `on_panic` panics.
I encountered such issues while changing libstd to debug/fix part of #28129.
While writing this I was wondering about which functions belong to `panicking` and which to `unwind`.
I placed them in this way mostly because of convenience, but I would strongly appreciate guidance.
Auto merge of #28612 - gandro:targetvendor, r=alexcrichton
This adds a new target property, `target_vendor`. It is to be be used as a matcher for conditional compilation. The vendor is part of the [autoconf target triple](http://llvm.org/docs/doxygen/html/classllvm_1_1Triple.html#details): `<arch><sub>-<vendor>-<os>-<env>`. `arch`, `target_os` and `target_env` are already supported by Rust.
This change was suggested in PR #28593. It enables conditional compilation based on the vendor. This is needed for the rumprun target, which needs to match against both, target_os and target_vendor.
The default value for `target_vendor` is "unknown", "apple" and "pc" are other common values.
Matching against the `target_vendor` is introduced behind the feature gate `#![feature(cfg_target_vendor)]`.
This is the first time I messed around with rustc internals. I just added the my code where I found the existing `target_*` variables, hopefully I haven't missed anything. Please review with care. :)
Steve Klabnik [Fri, 25 Sep 2015 19:33:32 +0000 (13:33 -0600)]
Rollup merge of #28654 - ogham:patch-2, r=sanxiyn
This was discovered by maggyero on #rust.
In the [documentation for the macros in libstd](https://doc.rust-lang.org/stable/std/#macros), the first lines for `print!` and `println!` were exactly the same, with no mention of how one of them also emits a newline:
<img width="622" alt="screen shot 2015-09-25 at 12 11 52" src="https://cloud.githubusercontent.com/assets/503760/10099409/465d509a-6381-11e5-9eb9-766f21a08c50.png">
This commit makes the first lines of those two macros different.
Alex Crichton [Thu, 24 Sep 2015 15:38:48 +0000 (08:38 -0700)]
std: Update MatchIndices to return a subslice
This commit updates the `MatchIndices` and `RMatchIndices` iterators to follow
the same pattern as the `chars` and `char_indices` iterators. The `matches`
iterator currently yield `&str` elements, so the `MatchIndices` iterator now
yields the index of the match as well as the `&str` that matched (instead of
start/end indexes).
Ben S [Fri, 25 Sep 2015 11:29:47 +0000 (12:29 +0100)]
Change the first line of the println macro doc
This makes the first lines of the print! and println! macros
different. Previously, they would show up exactly the same in the
documentation for the macros in libstd [1], with nothing about how
one of them also prints a newline.
Andrea Canciani [Thu, 24 Sep 2015 15:21:29 +0000 (17:21 +0200)]
Abort earlier upon multi-panics
The double-panic `abort` is run after the logging code, to provide
feedback in case of a double-panic. This means that if the panic
logging fails with a panic, the `abort` might never be reached.
This should not normally occur, but if the `on_panic` function detects
more than 2 panics, aborting *before* logging makes panic handling
somewhat more robust, as it avoids an infinite recursion, which would
eventually crash the process, but also make the problem harder to
debug.
This handles the FIXME about what to do if the thread printing panics.
Andrea Canciani [Thu, 24 Sep 2015 21:49:38 +0000 (23:49 +0200)]
Explicitly count the number of panics
Move the panic handling logic from the `unwind` module to `panicking`
and use a panic counter to distinguish between normal state, panics
and double panics.
Cleanup interfaces of Name, SyntaxContext and Ident
Make sure Name, SyntaxContext and Ident are passed by value
Make sure Idents don't serve as keys (or parts of keys) in maps, Ident comparison is not well defined
Auto merge of #28538 - alevy:make_fixedsizearray_unsafe, r=alexcrichton
[breaking-change]
`FixedSizeArray` is meant to be implemented for arrays of fixed size only, but can be implemented for anything at the moment. Marking the trait unsafe would make it more reasonable to write unsafe code which operates on fixed size arrays of any size.
For example, using `uninitialized` to create a fixed size array and immediately filling it with a fixed value is externally safe:
```
pub fn init_with_nones<T, A: FixedSizeArray<Option<T>>>() -> A {
let mut res = unsafe { mem::uninitialized() };
for elm in res.as_mut_slice().iter_mut() {
*elm = None;
}
res
}
```
But the same code is not safe if `FixedSizeArray` is implemented for other types:
Auto merge of #28607 - remram44:doc-fix-str-pattern, r=alexcrichton
Reported by Moonlightning on #rust
> 17:13 EDT < Moonlightning> I think I found a bug in the str::matches() documentation. Was it copied from str::split()? :p
> 17:13 EDT < Moonlightning> Because it says “The pattern can be a simple `&str`, `char`, or a closure that determines the split.”
I changed "determines the split" to "determines if a character matches".
It's not super clear, "determines the split" is not super clear to begin with, maybe this can be made better? On the other hand following the link to Pattern provides enough details.
Sebastian Wicki [Wed, 23 Sep 2015 23:20:43 +0000 (01:20 +0200)]
rustc: Add target_vendor for target triples
This adds a new target property, `target_vendor` which can be used as a
matcher for conditional compilation. The vendor is part of the autoconf
target triple: <arch><sub>-<vendor>-<os>-<env>
The default value for `target_vendor` is "unknown".
Matching against the `target_vendor` with `#[cfg]` is currently feature
gated as `cfg_target_vendor`.
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.
projects / rust.git / log