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!
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.
syntax_ext: format: fix implicit positional arguments
syntax_ext: format: don't panic if no args given for implicit positional args
Check the list lengths before use.
Fixes regression of `compile-fail/macro-backtrace-println.rs`.
syntax_ext: format: also map CountIsParam indices to expanded args
syntax_ext: format: fix ICE in case of malformed format args
Converts named argument references into indices, right after
verification as suggested by @alexcrichton. This drastically simplifies
the whole process!
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.
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!() }
```
r? @eddyb
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.
```rust
macro_rules! m { () => { let x = 1; x } }
macro_rules! n { () => {
m!() //< This can now expand into statements
}}
fn main() { n!(); }
```
and revert needless fallout fixes.
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.
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.
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.
Move variant_size_differences out of trans
Also enhances the error message a bit, fixes#30505 on the way, and adds
a test (which was missing).
Closes#34018
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.
Closes#28322
