- 19 1月, 2017 1 次提交
-
-
由 Jorge Aparicio 提交于
This calling convention is used to define interrup handlers on MSP430 microcontrollers. Usage looks like this: ``` rust #[no_mangle] #[link_section = "__interrupt_vector_10"] pub static TIM0_VECTOR: unsafe extern "msp430-interrupt" fn() = tim0; unsafe extern "msp430-interrupt" fn tim0() { P1OUT.write(0x00); } ``` which generates the following assembly: ``` asm Disassembly of section __interrupt_vector_10: 0000fff2 <TIM0_VECTOR>: fff2: 10 c0 interrupt service routine at 0xc010 Disassembly of section .text: 0000c010 <_ZN3msp4tim017h3193b957fd6a4fd4E>: c010: c2 43 21 00 mov.b #0, &0x0021 ;r3 As==00 c014: 00 13 reti ... ```
-
- 17 1月, 2017 2 次提交
-
-
由 Austin Bonander 提交于
-
由 Austin Bonander 提交于
* Add support for `#[proc_macro]` * Reactivate `proc_macro` feature and gate `#[proc_macro_attribute]` under it * Have `#![feature(proc_macro)]` imply `#![feature(use_extern_macros)]`, error on legacy import of proc macros via `#[macro_use]`
-
- 15 1月, 2017 2 次提交
-
-
由 est31 提交于
This marks the pushpop_unsafe feature as removed inside the feature_gate. It was added in commit 1829fa51 and then removed again in commit d399098f . Seems that the second commit forgot to mark it as removed in feature_gate.rs. This enables us to remove another element from the whitelist of non gate tested unstable lang features (issue #39059).
-
由 est31 提交于
This removes the safe_suggestion feature from feature_gate.rs. It was added in commit 164f0105 and then removed again in commit c11fe553 . As the removal was in the same PR #38099 as the addition, we don't move it to the "removed" section. Removes an element from the whitelist of non gate tested unstable lang features (issue #39059).
-
- 12 1月, 2017 1 次提交
-
-
由 Benjamin Saunders 提交于
-
- 11 1月, 2017 1 次提交
-
-
由 Andrew Paseltiner 提交于
CC #34761
-
- 03 1月, 2017 1 次提交
-
-
由 Alex Crichton 提交于
This commit stabilizes the `proc_macro` and `proc_macro_lib` features in the compiler to stabilize the "Macros 1.1" feature of the language. Many more details can be found on the tracking issue, #35900. Closes #35900
-
- 30 12月, 2016 3 次提交
-
-
由 Simonas Kazlauskas 提交于
-
由 est31 提交于
-
由 Simonas Kazlauskas 提交于
Dangling a carrot in front of a donkey. This commit includes manual merge conflict resolution changes from a rebase by @est31.
-
- 27 12月, 2016 1 次提交
-
-
由 Jorge Aparicio 提交于
- `--emit=asm --target=nvptx64-nvidia-cuda` can be used to turn a crate into a PTX module (a `.s` file). - intrinsics like `__syncthreads` and `blockIdx.x` are exposed as `"platform-intrinsics"`. - "cabi" has been implemented for the nvptx and nvptx64 architectures. i.e. `extern "C"` works. - a new ABI, `"ptx-kernel"`. That can be used to generate "global" functions. Example: `extern "ptx-kernel" fn kernel() { .. }`. All other functions are "device" functions.
-
- 20 12月, 2016 3 次提交
-
-
由 Guillaume Gomez 提交于
-
由 Guillaume Gomez 提交于
-
由 Guillaume Gomez 提交于
-
- 06 12月, 2016 1 次提交
-
-
由 Oliver Schneider 提交于
-
- 02 12月, 2016 2 次提交
-
-
由 Vadim Chugunov 提交于
-
由 Ariel Ben-Yehuda 提交于
This adds the new insta-stable `#![type_size_limit]` crate attribute to control the limit, and is obviously a [breaking-change] fixable by that.
-
- 30 11月, 2016 2 次提交
-
-
由 Johannes Oertel 提交于
Closes #37981.
-
由 Andrew Gallant 提交于
This commit adds a new attribute that instructs the compiler to emit target specific code for a single function. For example, the following function is permitted to use instructions that are part of SSE 4.2: #[target_feature = "+sse4.2"] fn foo() { ... } In particular, use of this attribute does not require setting the -C target-feature or -C target-cpu options on rustc. This attribute does not have any protections built into it. For example, nothing stops one from calling the above `foo` function on hosts without SSE 4.2 support. Doing so may result in a SIGILL. This commit also expands the target feature whitelist to include lzcnt, popcnt and sse4a. Namely, lzcnt and popcnt have their own CPUID bits, but were introduced with SSE4.
-
- 22 11月, 2016 1 次提交
-
-
由 Geoffry Song 提交于
This implements RFC 1624, tracking issue #37339. - `FnCtxt` (in typeck) gets a stack of `LoopCtxt`s, which store the currently deduced type of that loop, the desired type, and a list of break expressions currently seen. `loop` loops get a fresh type variable as their initial type (this logic is stolen from that for arrays). `while` loops get `()`. - `break {expr}` looks up the broken loop, and unifies the type of `expr` with the type of the loop. - `break` with no expr unifies the loop's type with `()`. - When building MIR, `loop` loops no longer construct a `()` value at termination of the loop; rather, the `break` expression assigns the result of the loop. `while` loops are unchanged. - `break` respects contexts in which expressions may not end with braced blocks. That is, `while break { break-value } { while-body }` is illegal; this preserves backwards compatibility. - The RFC did not make it clear, but I chose to make `break ()` inside of a `while` loop illegal, just in case we wanted to do anything with that design space in the future. This is my first time dealing with this part of rustc so I'm sure there's plenty of problems to pick on here ^_^
-
- 21 11月, 2016 3 次提交
-
-
由 Jeffrey Seyfried 提交于
-
由 Jeffrey Seyfried 提交于
-
由 Jeffrey Seyfried 提交于
-
- 20 11月, 2016 4 次提交
-
-
由 Jeffrey Seyfried 提交于
-
由 Jeffrey Seyfried 提交于
-
由 Jeffrey Seyfried 提交于
-
由 Jeffrey Seyfried 提交于
-
- 17 11月, 2016 1 次提交
-
-
由 Jeffrey Seyfried 提交于
-
- 16 11月, 2016 1 次提交
-
-
由 Alex Crichton 提交于
This commit is an implementation of [RFC 1721] which adds a new target feature to the compiler, `crt-static`, which can be used to select how the C runtime for a target is linked. Most targets dynamically linke the C runtime by default with the notable exception of some of the musl targets. [RFC 1721]: https://github.com/rust-lang/rfcs/blob/master/text/1721-crt-static.md This commit first adds the new target-feature, `crt-static`. If enabled, then the `cfg(target_feature = "crt-static")` will be available. Targets like musl will have this enabled by default. This feature can be controlled through the standard target-feature interface, `-C target-feature=+crt-static` or `-C target-feature=-crt-static`. Next this adds an gated and unstable `#[link(cfg(..))]` feature to enable the `crt-static` semantics we want with libc. The exact behavior of this attribute is a little squishy, but it's intended to be a forever-unstable implementation detail of the liblibc crate. Specifically the `#[link(cfg(..))]` annotation means that the `#[link]` directive is only active in a compilation unit if that `cfg` value is satisfied. For example when compiling an rlib, these directives are just encoded and ignored for dylibs, and all staticlibs are continued to be put into the rlib as usual. When placing that rlib into a staticlib, executable, or dylib, however, the `cfg` is evaluated *as if it were defined in the final artifact* and the library is decided to be linked or not. Essentially, what'll happen is: * On MSVC with `-C target-feature=-crt-static`, the `msvcrt.lib` library will be linked to. * On MSVC with `-C target-feature=+crt-static`, the `libcmt.lib` library will be linked to. * On musl with `-C target-feature=-crt-static`, the object files in liblibc.rlib are removed and `-lc` is passed instead. * On musl with `-C target-feature=+crt-static`, the object files in liblibc.rlib are used and `-lc` is not passed. This commit does **not** include an update to the liblibc module to implement these changes. I plan to do that just after the 1.14.0 beta release is cut to ensure we get ample time to test this feature. cc #37406
-
- 10 11月, 2016 1 次提交
-
-
由 Eduard Burtescu 提交于
-
- 09 11月, 2016 2 次提交
-
-
由 Brian Anderson 提交于
-
由 Vadim Petrochenkov 提交于
-
- 08 11月, 2016 1 次提交
-
-
由 Josh Driver 提交于
KNOWN_ATTRIBUTES should really be named BUILT_ATTRIBUTES, while KNOWN_ATTRIBUTES should be used to mark attributes as known, similar to USED_ATTRIBUTES.
-
- 06 11月, 2016 1 次提交
-
-
由 Alex Crichton 提交于
-
- 03 11月, 2016 2 次提交
-
-
由 Vadim Petrochenkov 提交于
-
由 Vadim Petrochenkov 提交于
-
- 01 11月, 2016 1 次提交
-
-
由 Alex Crichton 提交于
This commit is an implementation of [RFC 1665] which adds support for the `#![windows_subsystem]` attribute. This attribute allows specifying either the "windows" or "console" subsystems on Windows to the linker. [RFC 1665]: https://github.com/rust-lang/rfcs/blob/master/text/1665-windows-subsystem.md Previously all Rust executables were compiled as the "console" subsystem which meant that if you wanted a graphical application it would erroneously pop up a console whenever opened. When compiling an application, however, this is undesired behavior and the "windows" subsystem is used instead to have control over user interactions. This attribute is validated, but ignored on all non-Windows platforms. cc #37499
-
- 27 10月, 2016 2 次提交
-
-
由 Nick Cameron 提交于
-
由 Eduard Burtescu 提交于
-