> 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
add a test case for issue #32031
I propose a test case to finish the fix for issue #32031. Please review this commit thoroughly, as I have never written a codegen test before.
r? @eddyb
rustdoc: Don't generate empty files for stripped items
We need to traverse stripped modules to generate redirect pages, but we shouldn't generate
anything else for them.
This now renders the file contents to a Vec before writing it to a file in one go. I think
that's probably a better strategy anyway.
Fixes: #34025
Remove linking and intrinsics code made dead by only supporting LLVM 3.7 and up
This is mostly based on Alex's throwaway comment:
> probably reject those that LLVM just doesn't support...
So I'm more than happy to adjust the PR based on how you thought this should look. Also happy to split it into two PRs, one for linking and one for intrinsics.
r? @alexcrichton
/cc @nagisa @brson
Treat `#[test]` like `#[cfg(test)]` in non-test builds
This PR treats `#[test]` like `#[cfg(test)]` in non-test builds. In particular, like `#[cfg(test)]`,
- `#[test]` nodes are stripped during `cfg` processing, and
- `#[test]` is disallowed on non-optional expressions.
Closes#33946.
r? @nrc
Visit statement and expression attributes in the AST visitor
Currently, these attributes are not visited, so they are not gated feature checked in the post expansion visitor. This only affects crates using `#![feature(stmt_expr_attributes)]`.
r? @nrc
docs: Improve char::to_{lower,upper}case examples
Collect the results to a String to make it clear that it will not always
return only one char and add examples showing that.
r? @steveklabnik
Updated README to account for changes in MSYS2
One of the newest versions of MSYS2 now only has one .cmd file which replaces the old bat files. It has to be used to launch the mingw32/64 shell.
docs: simplify wording
It took me more then a moment to decipher "with no non-`'static`" thing :)
"`'static` type" should say the same thing more clearly.
r? @steveklabnik
Remove a gotcha from book/error-handling.md
The book's "Error handling with `Box<Error>`" section talks about `Box<Error>`. In the actual example `Box<Error + Send + Sync>` is used instead so that the corresponding From impls could be used to convert a plain string to an error type. Rust 1.7 added support for conversion from `&str`/`String` to
`Box<Error>`, so this gotcha and later references to it can now be removed.
r? @steveklabnik
Reflect supporting only LLVM 3.7+ in the LLVM wrappers
Based on 12abddb06b, it appears we can drop support for these older LLVM versions. Hopefully, this will make it slightly easier to support the changes needed for LLVM 3.9.
r? @nagisa
/cc @brson
Fix wrong statement in compare_exchange doc
The documentation for `core::sync::atomic::AtomicSomething::compare_exchange` contains a wrong, or imprecise, statement about the return value. It goes:
The return value is a result indicating whether the new value was written and containing
the previous value. On success this value is guaranteed to be equal to `new`.
In the second sentence, `this value` is gramatically understood as referring to `return value` from the first sentence. Due to how CAS works, the returned value is always what was in the atomic variable _before_ the operation occurred, not what was written into it during the operation. Hence, the fixed doc should say:
The return value is a result indicating whether the new value was written and containing
the previous value. On success this value is guaranteed to be equal to `current`.
This version is confirmed by the runnable examples in variants of `AtomicSomething`, e.g.
assert_eq!(some_bool.compare_exchange(true, false, Ordering::Acquire, Ordering::Relaxed),
Ok(true));
where the returned value is `Ok(current)`. This PR fixes all occurrences of this bug I could find.
An alternative solution would be to modify the second sentence so that it refers to the value _written_ into the Atomic rather than what was there before, in which case it would be correct. Example alternative formulation:
On success the value written into the `bool`/`usize`/`whatever` is guaranteed to be equal to `new`.
r? @steveklabnik
Improvements to pattern resolution + some refactoring
Continuation of https://github.com/rust-lang/rust/pull/33929
First commit is a careful rewrite of `resolve_pattern`, pattern path resolution and new binding creation logic is factored out in separate functions, some minor bugs are fixed. Also, `resolve_possibly_assoc_item` doesn't swallow modules now.
Later commits are refactorings, see the comment descriptions.
I intend to continue this work later with better support for `Def::Err` in patterns in post-resolve stages and cleanup of pattern resolution code in type checker.
Fixes https://github.com/rust-lang/rust/issues/32086
Fixes https://github.com/rust-lang/rust/issues/34047 ([breaking-change])
Fixes https://github.com/rust-lang/rust/issues/34074
cc @jseyfried
r? @eddyb
