| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
This commit renames a number of extension traits for slices and string
slices, now that they have been refactored for DST. In many cases,
multiple extension traits could now be consolidated. Further
consolidation will be possible with generalized where clauses.
The renamings are consistent with the [new `-Prelude`
suffix](https://github.com/rust-lang/rfcs/pull/344). There are probably
a few more candidates for being renamed this way, but that is left for
API stabilization of the relevant modules.
Because this renames traits, it is a:
[breaking-change]
However, I do not expect any code that currently uses the standard
library to actually break.
Closes #17917
|
|
Fixes #18649.
|
|
|
|
This should help with a potential race condition.
|
|
Unicode characters and strings.
Use `\u0080`-`\u00ff` instead. ASCII/byte literals are unaffected.
This PR introduces a new function, `escape_default`, into the ASCII
module. This was necessary for the pretty printer to continue to
function.
RFC #326.
Closes #18062.
[breaking-change]
|
|
documentation for new option.
|
|
Removes all target-specific knowledge from rustc. Some targets have changed
during this, but none of these should be very visible outside of
cross-compilation. The changes make our targets more consistent.
iX86-unknown-linux-gnu is now only available as i686-unknown-linux-gnu. We
used to accept any value of X greater than 1. i686 was released in 1995, and
should encompass the bare minimum of what Rust supports on x86 CPUs.
The only two windows targets are now i686-pc-windows-gnu and
x86_64-pc-windows-gnu.
The iOS target has been renamed from arm-apple-ios to arm-apple-darwin.
A complete list of the targets we accept now:
arm-apple-darwin
arm-linux-androideabi
arm-unknown-linux-gnueabi
arm-unknown-linux-gnueabihf
i686-apple-darwin
i686-pc-windows-gnu
i686-unknown-freebsd
i686-unknown-linux-gnu
mips-unknown-linux-gnu
mipsel-unknown-linux-gnu
x86_64-apple-darwin
x86_64-unknown-freebsd
x86_64-unknown-linux-gnu
x86_64-pc-windows-gnu
Closes #16093
[breaking-change]
|
|
|
|
|
|
Just to have it somewhere to point to. Updating it will not
automatically update the one on static.rust-lang.org.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- Stop highlighting foo in `use foo;` specially.
- Highlight `extern crate "foo" as bar;` properly.
- Highlight 1..2 according to the current grammar.
|
|
|
|
|
|
This wasn’t really consistent with other things; the last section of the
import was not highlighted in any other case.
Also `use {foo, bar};` was having the foo and bar not highlighted, where
they would have been as separate statements.
|
|
|
|
This change is an implementation of [RFC 69][rfc] which adds a third kind of
global to the language, `const`. This global is most similar to what the old
`static` was, and if you're unsure about what to use then you should use a
`const`.
The semantics of these three kinds of globals are:
* A `const` does not represent a memory location, but only a value. Constants
are translated as rvalues, which means that their values are directly inlined
at usage location (similar to a #define in C/C++). Constant values are, well,
constant, and can not be modified. Any "modification" is actually a
modification to a local value on the stack rather than the actual constant
itself.
Almost all values are allowed inside constants, whether they have interior
mutability or not. There are a few minor restrictions listed in the RFC, but
they should in general not come up too often.
* A `static` now always represents a memory location (unconditionally). Any
references to the same `static` are actually a reference to the same memory
location. Only values whose types ascribe to `Sync` are allowed in a `static`.
This restriction is in place because many threads may access a `static`
concurrently. Lifting this restriction (and allowing unsafe access) is a
future extension not implemented at this time.
* A `static mut` continues to always represent a memory location. All references
to a `static mut` continue to be `unsafe`.
This is a large breaking change, and many programs will need to be updated
accordingly. A summary of the breaking changes is:
* Statics may no longer be used in patterns. Statics now always represent a
memory location, which can sometimes be modified. To fix code, repurpose the
matched-on-`static` to a `const`.
static FOO: uint = 4;
match n {
FOO => { /* ... */ }
_ => { /* ... */ }
}
change this code to:
const FOO: uint = 4;
match n {
FOO => { /* ... */ }
_ => { /* ... */ }
}
* Statics may no longer refer to other statics by value. Due to statics being
able to change at runtime, allowing them to reference one another could
possibly lead to confusing semantics. If you are in this situation, use a
constant initializer instead. Note, however, that statics may reference other
statics by address, however.
* Statics may no longer be used in constant expressions, such as array lengths.
This is due to the same restrictions as listed above. Use a `const` instead.
[breaking-change]
Closes #17718
[rfc]: https://github.com/rust-lang/rfcs/pull/246
|
|
|
|
The tables in libunicode are far too large to want to be inlined into any other
program, so these tables are all going to remain `static`. For them to be legal,
they cannot reference one another by value, but instead use references now.
This commit also modifies the src/etc/unicode.py script to generate the right
tables.
|
|
Apart from making the build system determine the LLDB version, this PR also fixes an issue with enums in LLDB pretty printers. In order for GDB's pretty printers to know for sure if a field of some value is an enum discriminant, I had rustc mark discriminant fields with the `artificial` DWARF tag. This worked out nicely for GDB but it turns out that one can't access artificial fields from LLDB. So I changed the debuginfo representation so that enum discriminants are marked by the special field name `RUST$ENUM$DISR` instead, which works in both cases.
The PR does not activate the LLDB test suite yet.
|
|
LLDB doesn't allow for reading 'artifical' fields (fields that are generated by the compiler). So do not mark, slice fields, enum discriminants, and GcBox value fields as artificial.
|
|
|
|
|
|
Just to have it somewhere to point to. Updating it will not
automatically update the one on static.rust-lang.org.
|
|
|
|
Closes #17490
|
|
closes #17478
|
|
|
|
This makes the windows `make dist` target start producing binary tarballs, and tweaks install.sh so they work, in preparation for working on a combined Rust+Cargo installer.
|
|
Makes it work on windows
|
|
closes #17478
|
|
|
|
Modify the system %PATH% environment variable instead of the current
user's %PATH% environment. The current user will be an admin user
that may not be the same user who originally started the installer.
Closes #17570.
|
|
Everyone agreed.
Fix #17078
|
|
|
|
|
|
There are currently two huge problems with the indent file:
1. Long list-like things cannot be indented. See #14446 for one example. Another one is long enums with over 100 lines, including comments. The indentation process stops after 100 lines and the rest is in column 0.
2. In certain files, opening a new line at mod level is extremely slow. See [this](https://github.com/mahkoh/posix.rs/blob/master/src/unistd/mod.rs) for an example. Opening a line at the very end and holing \<cr> down will freeze vim temporarily.
The reason for 1. is that cindent doesn't properly indent things that end with a `,` and the indent file tries to work around this by using the indentation of the previous line. It does this by recursively calling a function on the previous lines until it reaches the start of the block. Naturally O(n^2) function calls don't scale very well. Instead of recalculating the indentation of the previous line, we will now simply use the given indentation of the previous line and let the user deal with the rest. This is sufficient unless the user manually mis-indents a line.
The reason for 2. seems to be function calls of the form
```
searchpair('{\|(', '', '}\|)', 'nbW', 's:is_string_comment(line("."), col("."))')
```
I've no idea what this even does or why it is there since I cannot reproduce the mistake cindent is supposed to make without this fix. Therefore I've simply removed that part.
|
|
Fixes #17251
|
|
This way the libs won't be on the -L library search path, and won't confuse external gcc, if one is used. The bundled gcc itself will still be able to find them, because it searches for libs relative to own install location.
|
|
|
|
|
|
Everyone agreed. Fix #17064, fix #17072
@brson OK?
|
|
|
