| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Expose all OS-specific modules in libstd doc.
1. Uses the special `--cfg dox` configuration passed by rustbuild when running `rustdoc`. Changes the `#[cfg(platform)]` into `#[cfg(any(dox, platform))]` so that platform-specific API are visible to rustdoc.
2. Since platform-specific implementations often won't compile correctly on other platforms, `rustdoc` is changed to apply `everybody_loops` to the functions during documentation and doc-test harness.
3. Since platform-specific code are documented on all platforms now, it could confuse users who found a useful API but is non-portable. Also, their examples will be doc-tested, so must be excluded when not testing on the native platform. An undocumented attribute `#[doc(cfg(...))]` is introduced to serve the above purposed.
Fixes #24658 (Does _not_ fully implement #1998).
|
|
|
|
|
|
This attribute has two effects:
1. Items with this attribute and their children will have the "This is
supported on **** only" message attached in the documentation.
2. The items' doc tests will be skipped if the configuration does not
match.
|
|
It's more pleasing to use the inner-attribute syntax (`#!` rather than
`#`) in the error message, as that is how `feature` attributes in
particular will be declared (as they apply to the entire crate).
|
|
|
|
|
|
Stabilizes:
* `compile_error!` as a macro defined by rustc
Closes #40872
|
|
Fix feature gate for `#[link_args(..)]` attribute
Fix feature gate for `#[link_args(..)]` attribute so that it will fire regardless of context of attribute.
See also #29596 and #43106
|
|
regardless of context of attribute.
Extend the gating test to include the attribute in "weird" places.
|
|
|
|
rustc: Implement the #[global_allocator] attribute
This PR is an implementation of [RFC 1974] which specifies a new method of
defining a global allocator for a program. This obsoletes the old
`#![allocator]` attribute and also removes support for it.
[RFC 1974]: https://github.com/rust-lang/rfcs/pull/1974
The new `#[global_allocator]` attribute solves many issues encountered with the
`#![allocator]` attribute such as composition and restrictions on the crate
graph itself. The compiler now has much more control over the ABI of the
allocator and how it's implemented, allowing much more freedom in terms of how
this feature is implemented.
cc #27389
|
|
This PR is an implementation of [RFC 1974] which specifies a new method of
defining a global allocator for a program. This obsoletes the old
`#![allocator]` attribute and also removes support for it.
[RFC 1974]: https://github.com/rust-lang/rfcs/pull/197
The new `#[global_allocator]` attribute solves many issues encountered with the
`#![allocator]` attribute such as composition and restrictions on the crate
graph itself. The compiler now has much more control over the ABI of the
allocator and how it's implemented, allowing much more freedom in terms of how
this feature is implemented.
cc #27389
|
|
|
|
|
|
|
|
|
|
|
|
This change allows the user to add an `#[allow_fail]` attribute to
tests that will cause the test to compile & run, but if the test fails
it will not cause the entire test run to fail. The test output will
show the failure, but in yellow instead of red, and also indicate that
it was an allowed failure.
|
|
Related to #40872
|
|
|
|
|
|
Remove all instances of fragment_infos and fragment sets
Remove unused fragment structs. This was suggested by @eddyb in IRC: [botbot link](https://botbot.me/mozilla/rustc/2017-05-23/?msg=86016574&page=2).
|
|
Stabilize non capturing closure to fn coercion
Stabilisation PR for non capturing closure to fn coercion.
closes #39817
|
|
|
|
add thiscall calling convention support
This support is needed for bindgen to work well on 32-bit Windows, and also enables people to begin experimenting with C++ FFI support on that platform.
Fixes #42044.
|
|
Initial implementation of declarative macros 2.0
Implement declarative macros 2.0 (rust-lang/rfcs#1584) behind `#![feature(decl_macro)]`.
Differences from `macro_rules!` include:
- new syntax: `macro m(..) { .. }` instead of `macro_rules! m { (..) => { .. } }`
- declarative macros are items:
```rust
// crate A:
pub mod foo {
m!(); // use before definition; declaration order is irrelevant
pub macro m() {} // `pub`, `pub(super)`, etc. work
}
fn main() {
foo::m!(); // named like other items
{ use foo::m as n; n!(); } // imported like other items
}
pub use foo::m; // re-exported like other items
// crate B:
extern crate A; // no need for `#[macro_use]`
A::foo::m!(); A::m!();
```
- Racket-like hygiene for items, imports, methods, fields, type parameters, privacy, etc.
- Intuitively, names in a macro definition are resolved in the macro definition's scope, not the scope in which the macro is used.
- This [explaination](http://beautifulracket.com/explainer/hygiene.html) of hygiene for Racket applies here (except for the "Breaking Hygiene" section). I wrote a similar [explanation](https://github.com/jseyfried/rfcs/blob/hygiene/text/0000-hygiene.md) for Rust.
- Generally speaking, if `fn f() { <body> }` resolves, `pub macro m() { <body> } ... m!()` also resolves, even if `m!()` is in a separate crate.
- `::foo::bar` in a `macro` behaves like `$crate::foo::bar` in a `macro_rules!`, except it can access everything visible from the `macro` (thus more permissive).
- See [`src/test/{run-pass, compile-fail}/hygiene`](https://github.com/rust-lang/rust/pull/40847/commits/afe7d89858fd72b983e24727d6f4058293153c19) for examples. Small example:
```rust
mod foo {
fn f() { println!("hello world"); }
pub macro m() { f(); }
}
fn main() { foo::m!(); }
```
Limitations:
- This does not address planned changes to matchers (`expr`,`ty`, etc.), c.f. #26361.
- Lints (including stability and deprecation) and `unsafe` are not hygienic.
- adding hygiene here will be mostly or entirely backwards compatible
- Nested macro definitions (a `macro` inside another `macro`) don't always work correctly when invoked from external crates.
- pending improvements in how we encode macro definitions in crate metadata
- There is no way to "escape" hygiene without using a procedural macro.
r? @nrc
|
|
|
|
|
|
|
|
This support is needed for bindgen to work well on 32-bit Windows, and
also enables people to begin experimenting with C++ FFI support on that
platform.
Fixes #42044.
|
|
|
|
Stabilize the loop_break_value feature
Tracking issue: #37339.
Documentation PRs already sent to the various repositories.
|
|
Correct some stability versions
These were found by running tidy on stable versions of rust and finding
features stabilised with the wrong version numbers.
|
|
These were found by running tidy on stable versions of rust and finding
features stabilised with the wrong version numbers.
|
|
|
|
|
|
This is mostly removing stray ampersands, needless returns and lifetimes.
|
|
When -Z profile is passed, the GCDAProfiling LLVM pass is added
to the pipeline, which uses debug information to instrument the IR.
After compiling with -Z profile, the $(OUT_DIR)/$(CRATE_NAME).gcno
file is created, containing initial profiling information.
After running the program built, the $(OUT_DIR)/$(CRATE_NAME).gcda
file is created, containing branch counters.
The created *.gcno and *.gcda files can be processed using
the "llvm-cov gcov" and "lcov" tools. The profiling data LLVM
generates does not faithfully follow the GCC's format for *.gcno
and *.gcda files, and so it will probably not work with other tools
(such as gcov itself) that consume these files.
|
|
`[default] [unsafe] impl` and typecheck
|
|
this commit implements the first step of the `default impl` feature:
all items in a `default impl` are (implicitly) `default` and hence
specializable.
In order to test this feature I've copied all the tests provided for the
`default` method implementation (in run-pass/specialization and
compile-fail/specialization directories) and moved the `default` keyword
from the item to the impl.
See referenced issue for further info
|
|
|
|
|
|
|
|
Prior to this commit, the contents of the Unstable Book were assumed to
be unstable features. This commit moves features into 'language features'
or 'library features' subsections. It also moves the 'linker_flavor'
compiler flag into a new 'Compiler Flags' subsection.
Even though it was helpful, I removed the tidy check that
cross-references the SUMMARY.md links with the Unstable Book directory
contents just because it would be difficult to maintain.
Relevant PR: https://github.com/rust-lang/rust/issues/41142.
|
|
|
|
|
|
I've added some explicit tests that negative impls are allowed to
overlap, and also to make sure that the feature doesn't interfere with
specialization. I've not added an explicit test for positive overlapping
with negative, as that's already tested elsewhere.
|
|
|
|
|
