Expand Attributes on Statements and Expressions
This enables attribute-macro expansion on statements and expressions while retaining the `stmt_expr_attributes` feature requirement for attributes on expressions.
closes#41475
cc #38356 @petrochenkov @jseyfried
r? @nrc
proc_macro: Tweak doc comments and negative literals
This commit tweaks the tokenization of a doc comment to use `#[doc = "..."]`
like `macro_rules!` does (instead of treating it as a `Literal` token).
Additionally it fixes treatment of negative literals in the compiler, for
exapmle `Literal::i32(-1)`. The current fix is a bit of a hack around the
current compiler implementation, providing a fix at the proc-macro layer rather
than the libsyntax layer.
Closes#48889
This commit tweaks the tokenization of a doc comment to use `#[doc = "..."]`
like `macro_rules!` does (instead of treating it as a `Literal` token).
Additionally it fixes treatment of negative literals in the compiler, for
exapmle `Literal::i32(-1)`. The current fix is a bit of a hack around the
current compiler implementation, providing a fix at the proc-macro layer rather
than the libsyntax layer.
rustc: Forbid #[inline(always)] with #[target_feature]
Once a target feature is enabled for a function that means that it in general
can't be inlined into other functions which don't have that target feature
enabled. This can cause both safety and LLVM issues if we were to actually
inline it, so `#[inline(always)]` both can't be respected and would be an error
if we did so!
Today LLVM doesn't inline functions with different `#[target_feature]`
annotations, but it turns out that if one is tagged with `#[inline(always)]`
it'll override this and cause scary LLVM error to arise!
This commit fixes this issue by forbidding these two attributes to be used in
conjunction with one another.
Closesrust-lang-nursery/stdsimd#404
This commit fixes a longstanding issue with the compiler with circular
dependencies between libcore and libstd. The `core` crate requires at least one
symbol, the ability to unwind. The `std` crate is the crate which actually
defines this symbol, but the `std` crate also depends on the `core` crate.
This circular dependency is in general disallowed in Rust as crates cannot have
cycles amongst them. A special exception is made just for core/std, but this is
also unfortunately incompatible with how GNU linkers work. GNU linkers will
process undefined symbols in a left-to-right fashion, only actually linking an
rlib like libstd if there are any symbols used from it. This strategy is
incompatible with circular dependencies because if we otherwise don't use
symbols from libstd we don't discover that we needed it until we're later
processing libcore's symbols!
To fix this GNU linkers support the `--start-group` and `--end-group` options
which indicate "libraries between these markers may have circular dependencies
amongst them. The linker invocation has been updated to automatically pass these
arguments when we're invoking a GNU linker and automatically calculate where the
arguments need to go (around libstd and libcore)
Closes#18807Closes#47074
Check for known but incorrect attributes
fixes#43988
- Change nested_visit_map so it will recursively check functions
- Add visit_stmt and visit_expr for impl Visitor for CheckAttrVisitor and check for incorrect
inline and repr attributes on staements and expressions
- Add regression test for issue #43988
Enable target_feature on any LLVM 6+
In `LLVMRustHasFeature()`, rather than using `MCInfo->getFeatureTable()`
that is specific to Rust's LLVM fork, we can use this in LLVM 6:
/// Check whether the subtarget features are enabled/disabled as per
/// the provided string, ignoring all other features.
bool checkFeatures(StringRef FS) const;
Now rustc using external LLVM can also have `target_feature`.
r? @alexcrichton
Stabilize match_default_bindings
This includes a submodule update to rustfmt
in order to allow a stable feature declaration.
r? @nikomatsakis
cc https://github.com/rust-lang/rust/issues/42640
Many of the tests this PR touches are merely testing the current lack of desired future behavior around https://github.com/rust-lang/rust/issues/44849 and https://github.com/rust-lang/rust/issues/44848 (cc @tschottdorf). I noticed the bullets for those items were checked on the tracking issue-- I've unchecked them, as they don't appear to have been completed and I don't see any comments indicating that we don't want to pursue them further. Still, I think it's fine to stabilize the current behavior, as I think expanding it in the future should be backwards-compatible.
An old fix for moves-in-guards had a hack for adjacent all-const match arms.
The hack was explained in a comment, which you can see here:
https://github.com/rust-lang/rust/pull/22580/files#diff-402a0fa4b3c6755c5650027c6d4cf1efR497
But hack was incomplete (and thus unsound), as pointed out here:
https://github.com/rust-lang/rust/issues/47295#issuecomment-357108458
Plus, it is likely to be at least tricky to reimplement this hack in
the new NLL borrowck.
So rather than try to preserve the hack, we want to try to just remove
it outright. (At least to see the results of a crater run.)
[breaking-change]
This is a breaking-change, but our hope is that no one is actually
relying on such an extreme special case. (We hypothesize the hack was
originally added to accommodate a file in our own test suite, not code
in the wild.)
Once a target feature is enabled for a function that means that it in general
can't be inlined into other functions which don't have that target feature
enabled. This can cause both safety and LLVM issues if we were to actually
inline it, so `#[inline(always)]` both can't be respected and would be an error
if we did so!
Today LLVM doesn't inline functions with different `#[target_feature]`
annotations, but it turns out that if one is tagged with `#[inline(always)]`
it'll override this and cause scary LLVM error to arise!
This commit fixes this issue by forbidding these two attributes to be used in
conjunction with one another.
cc rust-lang-nursery/stdsimd#404
In `LLVMRustHasFeature()`, rather than using `MCInfo->getFeatureTable()`
that is specific to Rust's LLVM fork, we can use this in LLVM 6:
/// Check whether the subtarget features are enabled/disabled as per
/// the provided string, ignoring all other features.
bool checkFeatures(StringRef FS) const;
Now rustc using external LLVM can also have `target_feature`.
