| Age | Commit message (Collapse) | Author | Lines |
|
|
|
Fixes https://github.com/rust-lang/rust/issues/28108.
|
|
Small formatting change
r? @steveklabnik
|
|
The spans of break and continue would include the next token.
|
|
@alexcrichton: The snapshot file is here: http://www.ntecs.de/downloads/rust/rust-stage0-2015-08-11-1af31d4-dragonfly-x86_64-08e7dd9d77434b377c0905cc5f8c705b2daf3a0e.tar.bz2.
This is the first part in getting Continuous builds for DragonFly (#16298).
|
|
|
|
|
|
|
|
|
|
r? @Gankro
|
|
r=alexcrichton
Fixed x variable identation. How it was displayed in Firefox before: http://s16.postimg.org/c9448tn0k/Screenshot_from_2015_09_01_17_35_43.jpg
|
|
Makes the code agree with the comment: 'value answers "am I locked?"'.
|
|
|
|
It is *very* easy to bypass, and is a relic of a bygone age where the type-checker was *much* less robust.
Fixes #27497
r? @nikomatsakis
|
|
|
|
Running TLS destructors for a MSVC Windows binary requires the linker doesn't
elide the `_tls_used` or `__tls_used` symbols (depending on the architecture).
This is currently achieved via a `#[link_args]` hack but this only works for
dynamically linked binaries because the link arguments aren't propagated to
statically linked binaries.
This commit alters the strategy to instead emit a volatile load from those
symbols so LLVM can't elide it, forcing the reference to the symbol to stay
alive as long as the callback function stays alive (which we've made sure of
with the `#[linkage]` attribute).
Closes #28111
|
|
Running TLS destructors for a MSVC Windows binary requires the linker doesn't
elide the `_tls_used` or `__tls_used` symbols (depending on the architecture).
This is currently achieved via a `#[link_args]` hack but this only works for
dynamically linked binaries because the link arguments aren't propagated to
statically linked binaries.
This commit alters the strategy to instead emit a volatile load from those
symbols so LLVM can't elide it, forcing the reference to the symbol to stay
alive as long as the callback function stays alive (which we've made sure of
with the `#[linkage]` attribute).
Closes #28111
|
|
|
|
Fixes #28154
|
|
This changes a lot of `.to_string()` to `.to_owned()`, removes a few redundant closures, and changes some `match`es to `if let`s.
I'm currently in the process of trying out clippy and acting on its suggestions. I started with compiletest, because we use it to test clippy, too. If this finds positive reception, I may continue refactoring other parts of the rust codebase.
|
|
|
|
r? @steveklabnik
|
|
|
|
Part of #24407
r? @Manishearth
|
|
This is a [breaking-change] for syntax extension authors. The fix is to use MultiModifier or MultiDecorator, which have the same functionality but are more flexible. Users of syntax extensions are unaffected.
|
|
Makes the code agree with the comment: 'value answers "am I locked?"'.
|
|
|
|
I believe everything that doesn't take a constant integer up to SSE4.2
should now be correct (I don't have any reason to believe that those
that do take constant integers are wrong; they're just more complicated
and I just haven't tested them in detail).
(Also, takes out two unused code paths from trans.)
|
|
|
|
closes #28093
|
|
I believe everything that doesn't take a constant integer up to SSE4.2
should now be correct (I don't have any reason to believe that those
that do take constant integers are wrong; they're just more complicated
and I just haven't tested them in detail).
|
|
|
|
This is a [breaking-change] for syntax extension authors. The fix is to use MultiModifier or MultiDecorator, which have the same functionality but are more flexible. Users of syntax extensions are unaffected.
|
|
It appears that these impls were left out of #25989 by mistake.
r? @alexcrichton
I'm not sure what the stability markers for these should be.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This adds a new Python script (compatible with 2.7 and 3.x) that will consume some JSON files that define a platform's intrinsics. It can output a file that defines the intrinsics in the compiler, or an `extern` block that will import them.
The complexity of the generator is to be DRY: platforms (especially ARM and AArch64) have a lot of repetition with their intrinsics, for different versions with different types, so being able to write it once is nice.
|
|
Fixes #27497
|
|
|
|
It appears that these impls were left out of #25989 by mistake.
|
|
r? @Manishearth
|
|
This was preventing any side-effects from the expressions from
happening.
Fixes #28114
cc @rust-lang/compiler
|
|
|
|
This was preventing any side-effects from the expressions from
happening.
Fixes #28114
|