rust/src/test/ui/custom_attribute.rs

#![feature(stmt_expr_attributes)]

#[foo] //~ ERROR cannot find attribute macro `foo` in this scope
fn main() {
    #[foo] //~ ERROR cannot find attribute macro `foo` in this scope
    let x = ();
    #[foo] //~ ERROR cannot find attribute macro `foo` in this scope
    x
}
Check that custom attributes are disallowed on statements and expressions 2016-06-10 10:36:21 +00:00			`#![feature(stmt_expr_attributes)]`

resolve: Use `feature(custom_attribute)` fallback only if the feature is enabled Normally `#![feature(...)]` shouldn't change behavior, but custom attributes in particular are in the process of retirement, and we should not produce a message telling to enable them. It also helps with unifying diagnostics for unresolved macros. 2019-07-12 01:00:20 +03:00			#[foo] //~ ERROR cannot find attribute macro `foo` in this scope
Add cfail test for custom attribute gate 2015-02-15 17:09:54 +05:30			`fn main() {`
resolve: Use `feature(custom_attribute)` fallback only if the feature is enabled Normally `#![feature(...)]` shouldn't change behavior, but custom attributes in particular are in the process of retirement, and we should not produce a message telling to enable them. It also helps with unifying diagnostics for unresolved macros. 2019-07-12 01:00:20 +03:00			#[foo] //~ ERROR cannot find attribute macro `foo` in this scope
Check that custom attributes are disallowed on statements and expressions 2016-06-10 10:36:21 +00:00			`let x = ();`
resolve: Use `feature(custom_attribute)` fallback only if the feature is enabled Normally `#![feature(...)]` shouldn't change behavior, but custom attributes in particular are in the process of retirement, and we should not produce a message telling to enable them. It also helps with unifying diagnostics for unresolved macros. 2019-07-12 01:00:20 +03:00			#[foo] //~ ERROR cannot find attribute macro `foo` in this scope
Check that custom attributes are disallowed on statements and expressions 2016-06-10 10:36:21 +00:00			`x`
Stabilize std::path This commit stabilizes essentially all of the new `std::path` API. The API itself is changed in a couple of ways (which brings it in closer alignment with the RFC): * `.` components are now normalized away, unless they appear at the start of a path. This in turn effects the semantics of e.g. asking for the file name of `foo/` or `foo/.`, both of which yield `Some("foo")` now. This semantics is what the original RFC specified, and is also desirable given early experience rolling out the new API. * The `parent` function now succeeds if, and only if, the path has at least one non-root/prefix component. This change affects `pop` as well. * The `Prefix` component now involves a separate `PrefixComponent` struct, to better allow for keeping both parsed and unparsed prefix data. In addition, the `old_path` module is now deprecated. Closes #23264 [breaking-change] 2015-03-09 08:49:10 -07:00			`}`