| Age | Commit message (Collapse) | Author | Lines |
|
|
|
|
|
"msp430-interrupt", "ptx-kernel" and #![compiler_builtins_lib]
|
|
#[used] attribute
(For an explanation of what this feature does, read the commit message)
I'd like to propose landing this as an experimental feature (experimental as in:
no clear stabilization path -- like `asm!`, `#[linkage]`) as it's low
maintenance (I think) and relevant to the "Usage in resource-constrained
environments" exploration area.
The main use case I see is running code before `main`. This could be used, for
instance, to cheaply initialize an allocator before `main` where the alternative
is to use `lazy_static` to initialize the allocator on its first use which it's
more expensive (atomics) and doesn't work on ARM Cortex-M0 microcontrollers (no
`AtomicUsize` on that platform)
Here's a `std` example of that:
``` rust
unsafe extern "C" fn before_main_1() {
println!("Hello");
}
unsafe extern "C" fn before_main_2() {
println!("World");
}
#[link_section = ".init_arary"]
#[used]
static INIT_ARRAY: [unsafe extern "C" fn(); 2] = [before_main_1, before_main_2];
fn main() {
println!("Goodbye");
}
```
```
$ rustc -C lto -C opt-level=3 before_main.rs
$ ./before_main
Hello
World
Goodbye
```
In general, this pattern could be used to let *dependencies* run code before
`main` (which sounds like it could go very wrong in some cases). There are
probably other use cases; I hope that the people I have cc-ed can comment on
those.
Note that I'm personally unsure if the above pattern is something we want to
promote / allow and that's why I'm proposing this feature as experimental. If
this leads to more footguns than benefits then we can just axe the feature.
cc @nikomatsakis ^ I know you have some thoughts on having a process for
experimental features though I'm fine with writing an RFC before landing this.
- `dead_code` lint will have to be updated to special case `#[used]` symbols.
- Should we extend `#[used]` to work on non-generic functions?
cc rust-lang/rfcs#1002
cc rust-lang/rfcs#1459
cc @dpc @JinShil
|
|
|
|
as it's specific to ELF and won't pass on macOS / Windows
|
|
|
|
|
|
|
|
|
|
[T]::rsplit() and rsplit_mut(), #41020
|
|
Add ptr::offset_to
This PR adds a method to calculate the signed distance (in number of elements) between two pointers. The resulting value can then be passed to `offset` to get one pointer from the other. This is similar to pointer subtraction in C/C++.
There are 2 special cases:
- If the distance is not a multiple of the element size then the result is rounded towards zero. (in C/C++ this is UB)
- ZST return `None`, while normal types return `Some(isize)`. This forces the user to handle the ZST case in unsafe code. (C/C++ doesn't have ZSTs)
|
|
|
|
|
|
|
|
This commit stabilizes the `#![windows_subsystem]` attribute which is a
conservative exposure of the `/SUBSYSTEM` linker flag on Widnows platforms. This
is useful for creating applications as well as console programs.
Closes #37499
|
|
Add missing link in unstable-book
add link to specialization's tracking issue
|
|
Add a tidy lint that checks for...
* Unstable Book sections with no corresponding SUMMARY.md links
* unstable features that don't have Unstable Book sections
* Unstable Book sections that don't have corresponding unstable features
|
|
add link to specialization's tracking issue
|
|
Avoid linking to a moved page in rust.html
|
|
|
|
r=steveklabnik
Add all unstable features to Unstable Book.
Add all unstable features to the Unstable Book, also remove a few that
either no longer exist or were promoted to stable.
These changes were extracted out of
https://github.com/rust-lang/rust/pull/40694
|
|
Add all unstable features to the Unstable Book, also remove a few that
either no longer exist or were promoted to stable.
These changes were extracted out of
https://github.com/rust-lang/rust/pull/40694
|
|
This includes an important fix for rustc contributors in
https://github.com/rust-lang/book/pull/571
I'm going to update the other ones as well here while we're at it; no
need to spam PRs.
|
|
Basic documentation for inclusive range syntax
Done so that we can remove mention of this from the stable documentation ⚠️.
|
|
Update the book submodule and fix tidy
When the book was included into https://github.com/rust-lang/rust as a submodule, tidy started failing on Windows.
https://github.com/rust-lang/book/pull/549 fixed the problem, now the submodule needs to be updated.
|
|
|
|
|
|
|
|
Add missing associated type Item to Iterator
|
|
Stabilize pub(restricted)
Fix https://github.com/rust-lang/rust/issues/32409
|
|
|
|
The unstable book, libstd, libcore, and liballoc all needed some
adjustment.
|
|
Some links needed adjustment to support this new scheme.
|
|
It's all in the external repository now.
|
|
We'll bring this back in with the next commit, as a submodule.
|
|
Add feature gate for rvalue-static-promotion
Probably needs more tests (which ones?) and there may be other things that need to be done. Also not sure whether the version that introduces the flag is really `1.15.1`.
See https://github.com/rust-lang/rfcs/pull/1414.
Updates #38865.
|
|
r=frewsxcv
add sort_unstable to unstable book
cc #40585
|
|
Using X headings #39850
Fix for issue #39850, the headings should now be 1, 2, and 3.
|
|
Remove doc about highlighting code in other languages #40301
This doesn't appear to be true any longer, so removing it to avoid confusion. See #40301
Thoughts:
- may be a good idea to remove "Let's discuss the details of these code blocks.", as there's not much being discussed at this point;
- does `text` still work?
r? @steveklabnik
|
|
Update usages of 'OSX' (and other old names) to 'macOS'.
As of last year with version 'Sierra', the Mac operating system is now
called 'macOS'.
|
|
r=GuillaumeGomez
Remove function invokation parens from documentation links.
This was never established as a convention we should follow in the 'More
API Documentation Conventions' RFC:
https://github.com/rust-lang/rfcs/blob/master/text/1574-more-api-documentation-conventions.md
|
|
cc #40585
|
|
|
|
|
|
See https://github.com/rust-lang/rfcs/pull/1414.
Updates #38865.
|
|
This was never established as a convention we should follow in the 'More
API Documentation Conventions' RFC:
https://github.com/rust-lang/rfcs/blob/master/text/1574-more-api-documentation-conventions.md
|
|
|
|
|
|
|