Auto merge of #34779 - infinity0:master, r=alexcrichton
If local-rust is the same as the current version, then force a local-rebuild
In Debian, we would like the option to build/rebuild the current release from
*either* the current or previous stable release. So we use enable-local-rust
instead of enable-local-rebuild, and read the bootstrap key dynamically from
whatever is installed locally.
In general, it does not make much sense to allow enable-local-rust without also
setting the bootstrap key, since the build would fail otherwise.
(The way I detect "the bootstrap key of [the local] rustc installation" is a bit hacky, suggestions welcome.)
Auto merge of #34676 - aravind-pg:inner-attr, r=brson
Better error message for inner attribute following doc comment
Before it was always just "an inner attribute is not permitted in this context", whereas now we add a special case for when an inner attr follows an outer attr. If the outer attr is a doc comment, then the error is "an inner attr is not permitted following a doc comment", and otherwise it's "an inner attr is not permitted following an outer attribute". In all other cases it's still "an inner attribute is not permitted in this context".
Note that the public API and behaviour of `parse_attribute` is unchanged. Also, all new names are very open to bikeshedding -- they're arguably clunky.
Auto merge of #34841 - alexcrichton:no-mips-soft-float, r=brson
mk: Don't pass -msoft-float on mips-gnu
Soon the LLVM upgrade (#34743) will require an updated CMake installation, and
the easiest way to do this was to upgrade the Ubuntu version of the bots to
16.04. This in turn brings in a new MIPS compiler on the linux-cross builder,
which is now from the "official" ubuntu repositories. Unfortunately these
new compilers don't support compiling with the `-msoft-float` flag like we're
currently passing, causing compiles to fail.
This commit removes these flags as it's not clear *why* they're being passed, as
the mipsel targets also don't have it. At least if it's not supported by a
debian default compiler, perhaps it's not too relevant to support?
Alex Crichton [Fri, 15 Jul 2016 04:48:41 +0000 (21:48 -0700)]
mk: Don't pass -msoft-float on mips-gnu
Soon the LLVM upgrade (#34743) will require an updated CMake installation, and
the easiest way to do this was to upgrade the Ubuntu version of the bots to
16.04. This in turn brings in a new MIPS compiler on the linux-cross builder,
which is now from the "official" ubuntu repositories. Unfortunately these
new compilers don't support compiling with the `-msoft-float` flag like we're
currently passing, causing compiles to fail.
This commit removes these flags as it's not clear *why* they're being passed, as
the mipsel targets also don't have it. At least if it's not supported by a
debian default compiler, perhaps it's not too relevant to support?
This PR removes renaming from the hygiene algorithm and treats differently marked identifiers as unequal.
This change makes the scope of identifiers in `macro_rules!` items empty. That is, identifiers in `macro_rules!` definitions do not inherit any semantics from the `macro_rules!`'s scope.
Since `macro_rules!` macros are items, the scope of their identifiers "should" be the same as that of other items; in particular, the scope should contain only items. Since all items are unhygienic today, this would mean the scope should be empty.
However, the scope of an identifier in a `macro_rules!` statement today is the scope that the identifier would have if it replaced the `macro_rules!` (excluding anything unhygienic, i.e. locals only).
To continue to support this, this PR tracks the scope of each `macro_rules!` and uses it in `resolve` to ensure that an identifier expanded from a `macro_rules!` gets a chance to resolve to the locals in the `macro_rules!`'s scope.
This PR is a pure refactoring. After this PR,
- `syntax::ext::expand` is much simpler.
- We can expand macros in any order without causing problems for hygiene (needed for macro modularization).
- We can deprecate or remove today's `macro_rules!` scope easily.
- Expansion performance improves by 25%, post-expansion memory usage decreases by ~5%.
- Expanding a block is no longer quadratic in the number of `let` statements (fixes #10607).
Rollup merge of #34799 - wuranbo:patch-3, r=steveklabnik
doc: ffi referenced rust-snappy can not compile
r? @steveklabnik
The referenced code https://github.com/thestinger/rust-snappy can not work. Maybe it's the old rust version? I do not know.
So I try to rewrite these test cases. If it is not what you originally meaning, just ignored it.
Auto merge of #34797 - doomrobo:fix-import-trait-method, r=jseyfried
Fixed issue where importing a trait method directly and then calling the method causes a compiler panic
The code below triggers the panic, and is included in a new regression test.
```rust
trait Foo {
fn foo();
}
use Foo::foo;
fn main() {
foo();
}
```
The bug is caused by `librustc_resolve` allowing the illegal binding to be imported even after displaying the error message above.
The fix amounts to importing a dummy binding (`rustc::hir::def::Def::Err`) instead of the actual trait method.
Auto merge of #34824 - alexcrichton:fix-nightlies, r=brson
test: Remove NOTE assertions from trace_macros-gate
If no NOTE assertions are present I believe they aren't asserted at all, and it
looks like the number of NOTEs differs on distcheck vs `make check`, so let's
just remove them all.
Alex Crichton [Thu, 14 Jul 2016 17:27:56 +0000 (10:27 -0700)]
test: Remove NOTE assertions from trace_macros-gate
If no NOTE assertions are present I believe they aren't asserted at all, and it
looks like the number of NOTEs differs on distcheck vs `make check`, so let's
just remove them all.
Auto merge of #34783 - Dridi:cdylib_usage, r=alexcrichton
Mention the crate type cdylib in rustc's usage
Hello,
I just tried to build a `cdylib` with the latest stable release, I've been passively waiting for this for quite some time now. Tested successfully on my machine, although it doesn't appear in `rustc`'s usage it seems to work like a charm so far. :grinning:
Auto merge of #34776 - cuviper:solaris-readdir, r=alexcrichton
std: fix `readdir` errors for solaris
A `NULL` from `readdir` could be the end of stream or an error. The only
way to know is to check `errno`, so it must be set to a known value first,
like a 0 that POSIX will never use.
This currently only matters for solaris targets, as the other unix platforms
are using `readdir_r` with a direct error return indication. However, this is
getting deprecated (#34668) so they should all eventually switch to `readdir`.
This PR adds `set_errno`, uses it to clear the value before calling `readdir`,
then checks it again after to see the reason for a `NULL`. A few other small
fixes are included just to get solaris compiling at all.
I couldn't get cross-compilation completely going, so I don't have a good way
to test this beyond a smoke-test cargo build of std. I'd appreciate input from
someone more familiar with solaris -- cc @nbaksalyar?
Auto merge of #33642 - xen0n:ergonomic-format-macro, r=alexcrichton
Ergonomic format_args!
Fixes #9456 (at last).
Not a ground-up rewrite of the existing machinery, but more like an added intermediary layer between macro arguments and format placeholders. This is now implementing Rust RFC 1618!
Wang Xuerui [Sat, 14 May 2016 12:42:47 +0000 (20:42 +0800)]
syntax_ext: format: allow multiple formats for one argument
This commit removed the restriction of only allowing one type per argument.
This is achieved by adding mappings between macro arguments and format
placeholders, then taking the mapping into consideration when emitting
the Arguments expression.
Wang Xuerui [Sun, 5 Jun 2016 12:39:05 +0000 (20:39 +0800)]
syntax_ext: format: resolve named arguments early
Converts named argument references into indices, right after
verification as suggested by @alexcrichton. This drastically simplifies
the whole process!
Wang Xuerui [Mon, 16 May 2016 17:02:42 +0000 (01:02 +0800)]
format: remove all implicit ref handling outside of libfmt_macros
format: beautifully get rid of ArgumentNext and CountIsNextParam
Now that CountIsNextParam and ArgumentNext are resolved during parse,
the need for handling them outside of libfmt_macros is obviated.
Note: *one* instance of implicit reference handling still remains, and
that's for implementing `all_args_simple`. It's trivial enough though,
so in this case it may be tolerable.
Auto merge of #34752 - ollie27:rustdoc_search, r=GuillaumeGomez
rustdoc: Fix methods in seach results
Currently methods from extern crates are sometimes added to the search
index when they shouldn't be or added with the original path rather than
the reexported path. This fixes that by making sure `cache().paths` only
contains local paths like the description for it states. It also fixes a
few minor issues with link rendering and redirect generation which would
point to local crate docs even if the docs for that crate hadn't been
generated.
Also a bug with methods implemented on traits which caused wrong paths and
so dead links in the search results has been fixed.
The referenced code https://github.com/thestinger/rust-snappy can not work. Maybe it's the old rust version? I do not know.
So I try to rewrite these test cases. If it is not what you originally meaning, just ignored it.
Auto merge of #34660 - jseyfried:fix_parse_stmt, r=nrc
Fix bugs in macro-expanded statement parsing
Fixes #34543.
This is a [breaking-change]. For example, the following would break:
```rust
macro_rules! m { () => {
println!("") println!("")
//^ Semicolons are now required on macro-expanded non-braced macro invocations
//| in statement positions.
let x = 0
//^ Semicolons are now required on macro-expanded `let` statements
//| that are followed by more statements, so this would break.
let y = 0 //< (this would still be allowed to reduce breakage in the wild)
}
fn main() { m!() }
```
Auto merge of #34756 - habnabit:mutex-refunwindsafe, r=alexcrichton
Mutex and RwLock need RefUnwindSafe too
Incomplete, because I don't know what the appropriate stability annotation is here, but this is an attempt to bring the documentation for `std::panic` in line with reality. Right now, it says:
>Types like `&Mutex<T>`, however, are unwind safe because they implement poisoning by default.
But only `Mutex<T>`, not `&Mutex<T>`, is unwind-safe.
Auto merge of #34739 - therealbstern:ipv4unspec, r=alexcrichton
Mark Ipv4Addr is_unspecified as stable and provide reference.
Per [#27709 (comment)](https://github.com/rust-lang/rust/issues/27709#issuecomment-231280999), no RFC is needed here.
IPv4 "unspecified" has been defined in [Stevens], and has been part of the IPv4 stack for quite some time. This property should become stable, since this use of 0.0.0.0 is not going anywhere.
[Stevens][_UNIX Network Programming Volume 1, Second Edition_. Stevens, W. Richard. Prentice-Hall, 1998. p. 891]
Please let me know if I got the rustdoc wrong or something. I tried to be as terse as possible while still conveying the appropriate information.
This also has a slight impact on PR #34694, but that one came first, so this shouldn't block it, IMO.
Auto merge of #34705 - alexcrichton:clean-deprecated, r=brson
std: Clean out deprecated APIs
This primarily removes a lot of `sync::Static*` APIs and rejiggers the
associated implementations. While doing this it was discovered that the
`is_poisoned` method can actually result in a data race for the Mutex/RwLock
primitives, so the inner `Cell<bool>` was changed to an `AtomicBool` to prevent
the associated data race. Otherwise the usage/gurantees should be the same
they were before.
Alex Crichton [Thu, 7 Jul 2016 18:46:09 +0000 (11:46 -0700)]
std: Clean out deprecated APIs
This primarily removes a lot of `sync::Static*` APIs and rejiggers the
associated implementations. While doing this it was discovered that the
`is_poisoned` method can actually result in a data race for the Mutex/RwLock
primitives, so the inner `Cell<bool>` was changed to an `AtomicBool` to prevent
the associated data race. Otherwise the usage/gurantees should be the same
they were before.
Currently methods from extern crates are sometimes added to the search
index when they shouldn't be or added with the original path rather than
the reexported path. This fixes that by making sure `cache().paths` only
contains local paths like the description for it states. It also fixes a
few minor issues with link rendering and redirect generation which would
point to local crate docs even if the docs for that crate hadn't been
generated.
Also a bug with methods implemented on traits which caused wrong paths and
so dead links in the search results has been fixed.
Josh Stone [Tue, 12 Jul 2016 04:43:53 +0000 (21:43 -0700)]
std: clear errno before readdir, then check it (solaris)
A `NULL` from `readdir` could be the end of stream or an error. The
only way to know is to check `errno`, so it must be set to a known value
first, like a 0 that POSIX will never use.
This patch adds `set_errno`, uses it to clear the value before calling
`readdir`, then checks it again after to see the reason for a `NULL`.
Josh Stone [Tue, 12 Jul 2016 04:35:47 +0000 (21:35 -0700)]
std: Fix `Thread::set_name()` for newlib and solaris
The `use ffi::CStr` in `unix/thread.rs` was previously guarded, but now
all platforms need it for `Thread::set_name()`. Newlib and Solaris do
nothing here, as they have no way to set a thread name, but they still
define the same method signature.
Auto merge of #33971 - bltavares:28322/default-channel-to-stable-on-tarball, r=brson
Use --release-channel=stable by default on releases
> Release tarballs should be compilable with just basic ./configure ;
> make ; sudo make install without having to pass special flags to
> configure. This is the case of the --release-channel option, that must
> be changed in the releases.
This commit detects the presence of .git, as it happens on other parts
of `configure` to assume it is a tarball. Then it changes the default
value stored, before parsing the arguments, while still allowing it to
be overriden before any action verifying the flag is done.