This addresses the font lock regression introduced by the earlier pull
request #14818 - attributes are no longer be highligted inside of comments
and strings.
Also add some font lock test infrastructure and some tests for attribute
font locking.
This commit is the final step in the libstd facade, #13851. The purpose of this
commit is to move libsync underneath the standard library, behind the facade.
This will allow core primitives like channels, queues, and atomics to all live
in the same location.
There were a few notable changes and a few breaking changes as part of this
movement:
* The `Vec` and `String` types are reexported at the top level of libcollections
* The `unreachable!()` macro was copied to libcore
* The `std::rt::thread` module was moved to librustrt, but it is still
reexported at the same location.
* The `std::comm` module was moved to libsync
* The `sync::comm` module was moved under `sync::comm`, and renamed to `duplex`.
It is now a private module with types/functions being reexported under
`sync::comm`. This is a breaking change for any existing users of duplex
streams.
* All concurrent queues/deques were moved directly under libsync. They are also
all marked with #![experimental] for now if they are public.
* The `task_pool` and `future` modules no longer live in libsync, but rather
live under `std::sync`. They will forever live at this location, but they may
move to libsync if the `std::task` module moves as well.
[breaking-change]
Part of #14248
Main contributors are @pcwalton, @alexcrichton and me. Only
@dguenther appear in git blame as a minor contribution, but it is
only adding the rust license, so removed by this relicensing.
part of #14248, fix#14420
Removed @richo's contribution (outdated comment)
Quoting @brson: let's move forward with this one. The only
statement I'm missing is @richo's and it sounds like his was a
minor patch.
This is part of the ongoing renaming of the equality traits. See #12517 for more
details. All code using Eq/Ord will temporarily need to move to Partial{Eq,Ord}
or the Total{Eq,Ord} traits. The Total traits will soon be renamed to {Eq,Ord}.
cc #12517
[breaking-change]
Attempt to highlight the placement expression in a `box (expr) foo`
expression. Also treat GC as a keyword within the placement expression.
This doesn't work correctly for arbitrary expressions. Notably, this
makes no attempt at balancing delimiters. I believe handling that will
require rewriting the syntax rules to add a region for every pair of
delimiters. That may be a desirable thing to do in the end, because we
can then rewrite our indent rules based on the syntax and get rid of
cindent(), but for the time being, we'll just live with the limitation.
Two line summary: Distinguish HOST_RPATH and TARGET_RPATH; added
RPATH_LINK_SEARCH; skip tests broken in stage1; general cleanup.
`HOST_RPATH_VAR$(1)_T_$(2)_H_$(3)` and `TARGET_RPATH_VAR$(1)_T_$(2)_H_$(3)`
both match the format of the old `RPATH_VAR$(1)_T_$(2)_H_$(3)` (which
is still being set the same way that it was before, to one of either
HOST/TARGET depending on what stage we are building). Namely, the format
is <XXX>_RPATH_VAR = "<LD_LIB_PATH_ENVVAR>=<COLON_SEP_PATH_ENTRIES>"
What this commit does:
* Pass both of the (newly introduced) HOST and TARGET rpath setup vars
to `maketest.py`
* Update `maketest.py` to no longer update the LD_LIBRARY_PATH itself
Instead, it passes along the HOST and TARGET rpath setup vars in
environment variables `HOST_RPATH_ENV` and `TARGET_RPATH_ENV`
* Also, pass the current stage number to maketest.py; it in turn
passes it (via an env var) to run-make tests.
This allows the run-make tests to selectively change behavior
(e.g. turn themselves off) to deal with incompatibilities with
e.g. stage1.
* Cleanup: Distinguish in tools.mk between the command to run (`RUN`)
and the file to generate to drive that command (`RUN_BINFILE`). The
main thing this enables is that `RUN` can now setup the
`TARGET_RPATH_ENV` without having to dirty up the runner code in
each of the `run-make` Makefiles.
* Cleanup: Factored out commands to delete dylib/rlib into
REMOVE_DYLIBS/REMOVE_RLIBS.
There were places where we were only calling `rm $(call DYLIB,foo)`
even though we really needed to get rid of the whole glob (at least
based on alex's findings on #13753 that removing the symlink does not
suffice).
Therefore rather than peppering the code with the awkward
`rm $(TMPDIR)/$(call DYLIB_GLOB,foo)`, I instead introduced a common
`REMOVE_DYLIBS` user function that expands into that when called.
After I adding an analogous `REMOVE_RLIBS`, I changed all of the
existing calls that rm dylibs or rlibs to use these routines
instead.
Note that the latter is not a true refactoring since I may have
changed cases where it was our intent to only remove the sym-link.
(But if that is the case, then we need to more deeply investigate
alex's findings on #13753 where the system was still dynamically
loading up the non-symlinked libraries that it finds on the load
path.)
* Added RPATH_LINK_SEARCH command and use it on Linux.
On some platforms, namely Linux, when you have libboot.so that has
its internal rpath set (to e.g. $(ORIGIN)/path/to/HOSTDIR), the
linker still complains when you do the link step and it does not
know where to find libraries that libboot.so depends upon that live
in HOSTDIR (think e.g. librustuv.so).
As far as I can tell, the GNU linker will consult the
LD_LIBRARY_PATH as part of the linking process to find such
libraries. But if you want to be more careful and not override
LD_LIBRARY_PATH for the `gcc` invocation, then you need some other
way to tell the linker where it can find the libraries that
libboot.so needs. The solution to this on Linux is the
`-Wl,-rpath-link` command line option.
However, this command line option does not exist on Mac OS X, (which
appears to be figuring out how to resolve the libboot.dylib
dependency by some other means, perhaps by consulting the rpath
setting within libboot.dylib).
So, in order to abstract over this distinction, I added the
RPATH_LINK_SEARCH macro to the run-make infrastructure and added
calls to it where necessary to get Linux working. On architectures
other than Linux, the macro expands to nothing.
* Disable miscellaneous tests atop stage1.
* An especially interesting instance of the previous bullet point:
Excuse regex from doing rustdoc tests atop stage1.
This was a (nearly-) final step to get `make check-stage1` working
again.
The use of a special-case check for regex here is ugly but is
analogous other similar checks for regex such as the one that landed
in PR #13844.
The way this is written, the user will get a reminder that
doc-crate-regex is being skipped whenever their rules attempt to do
the crate documentation tests. This is deliberate: I want people
running `make check-stage1` to be reminded about which cases are
being skipped. (But if such echo noise is considered offensive, it
can obviously be removed.)
* Got windows working with the above changes.
This portion of the commit is a cleanup revision of the (previously
mentioned on try builds) re-architecting of how the LD_LIBRARY_PATH
setup and extension is handled in order to accommodate Windows' (1.)
use of `$PATH` for that purpose and (2.) use of spaces in `$PATH`
entries (problematic for make and for interoperation with tools at
the shell).
* In addition, since the code has been rearchitected to pass the
HOST_RPATH_DIR/TARGET_RPATH_DIR rather than a whole sh
environment-variable setting command, there is no need to for the
convert_path_spec calls in maketest.py, which in fact were put in
place to placate Windows but were now causing the Windows builds to
fail. Instead we just convert the paths to absolute paths just like
all of the other path arguments.
Also, note for makefile hackers: apparently you cannot quote operands
to `ifeq` in Makefile (or at least, you need to be careful about
adding them, e.g. to only one side).
There's no need to include this specific flag just for android. We can
already deal with what it tries to solve by using -C linker=/path/to/cc
and -C ar=/path/to/ar. The Makefiles for rustc already set this up when
we're crosscompiling.
I did add the flag to compiletest though so it can find gdb. Though, I'm
pretty sure we don't run debuginfo tests on android anyways right now.
[breaking-change]
The Normalizations iterator has been renamed to Decompositions.
It does not currently include all forms of Unicode normalization,
but only encompasses decompositions.
If implemented recomposition would likely be a separate iterator
which works on the result of this one.
[breaking-change]
cindent handles the following case incorrectly:
impl X {
b: int,
//
c: int,
}
if you try and insert a new line after the `c` declaration.
To fix this, fix the get_line_trimmed() function to work properly, and
then extend GetRustIndent to keep searching backwards until it finds a
non-blank line after trimming. This lets it handle the trailing comma
case properly, as if the comment were never there.
Fixes#14041.
If an unbalanced [ exists in a string or comment, this should not be
considered when calculating the indent at the top level.
Similarly, when testing for ({/}) to see if we're at the top level to
begin with, strings and comments should be skipped.
If an unbalanced [ exists in a string or comment, this should not be
considered when calculating the indent at the top level.
Similarly, when testing for ({/}) to see if we're at the top level to
begin with, strings and comments should be skipped.
The change in #13600 was incorrect, containing a bad regular expression;
inside an indent function, errors are silently ignored (and the ``~=``
operation will return 0), so it just always failed, causing the cases
that were supposed to be caught to not be caught and making things like
the ``match`` example shown above or struct field definitions regress.
I have fixed the regular expression to what it should have been. This is
still imperfect, of course, not handling cases like where the first
argument to a function is a function call (``foo(bar(),``), but it'll do
for now.
This is a bit of an interesting upgrade to LLVM. Upstream LLVM has started using C++11 features, so they require a C++11 compiler to build. I've updated all the bots to have a C++11 compiler, and they appear to be building LLVM successfully:
* Linux bots - I added gcc/g++ 4.7 (good enough)
* Android bots - same as the linux ones
* Mac bots - I installed the most recent command line tools for Lion which gives us clang 3.2, but LLVM wouldn't build unless it was explicitly asked to link to `libc++` instead of `libstdc++`. This involved tweaking `mklldeps.py` and the `configure` script to get things to work out
* Windows bots - mingw-w64 has gcc 4.8.1 which is sufficient for building LLVM (hurray!)
* BSD bots - I updated FreeBSD to 10.0 which brought with it a relevant version of clang.
The largest fallout I've seen so far is that the test suite doesn't work at all on FreeBSD 10. We've already stopped gating on FreeBSD due to #13427 (we used to be on freebsd 9), so I don't think this puts us in too bad of a situation. I will continue to attempt to fix FreeBSD and the breakage on there.
The LLVM update brings with it all of the recently upstreamed LLVM patches. We only have one local patch now which is just an optimization, and isn't required to use upstream LLVM. I want to maintain compatibility with LLVM 3.3 and 3.4 while we can, and this upgrade is keeping us up to date with the 3.5 release. Once 3.5 is release we will in theory no longer require a bundled LLVM.
When calling a function, or anything with nested parens,
default to cindent's indent. The least error-prone way I
could think of identifying this is to look for a line
that ends with a ',', as well as a non-zero number of
any character except parens before the comma, and
then an open paren.
This will overlap with the previous rule accounting for
function definitions, but that should be fine because
it is also using cindent.
The goal of the snapshot bots is to produce binaries which can run in as many
locations as possible. Currently we build on Centos 6 for this reason, but with
LLVM's update to C++11, this reduces the number of platforms that we could
possibly run on.
This adds a --enable-llvm-static-stdcpp option to the ./configure script for
Rust which will enable building a librustc with a static dependence on
libstdc++. This normally isn't necessary, but this option can be used on the
snapshot builders in order to continue to make binaries which should be able to
run in as many locations as possible.
When clang is enabled, also pass through --enable-libcpp to LLVM's configure
command line to help it pick up the most recent c++ runtime library. This also
changes the mklldeps.py script to pick up on whether LLVM was linked against
stdc++ or c++ based on the --cxxflags that llvm-config prints.
In an ongoing attempt to update LLVM, the bots need to update their C compilers
to something that supports c++11 (LLVM recently switched). The OSX bots are
running Lion (10.7), which only supports up to gcc 4.2 and clang 3.2. Apparently
the libstdc++ is too old (even on the most updated command line tools) for LLVM,
but using libc++ instead appears to work just fine.
* Use `setq-local` instead of `(set (make-local-variable 'var) value)`. Provides a version for older Emacsen.
* Remove use of `cl.el`.
* Use \' in file regexp instead of line end match $.
* Use type for `defcustom` and add parent group.
* Use `setq-local' instead of (set (make-local-variable ...) value).
Provides a version for older Emacsen.
* Remove use of `cl.el'.
* Use \' in file regexp instead of line end match $.
* Use type for defcustom and add parent group.
Few places where previous version of tidy script cannot find XXX:
* inside one-line comment preceding by a few spaces;
* inside multiline comments (now it finds it if multiline comment starts
on the same line with XXX).
Change occurences of XXX found by new tidy script.
Rust currently defaults to `RelocPIC` regardless. This patch adds a new
codegen option that allows choosing different relocation-model. The
available models are:
- default (Use the target-specific default model)
- static
- pic
- no-pic
For a more detailed information use `llc --help`
Rust currently defaults to `RelocPIC` regardless. This patch adds a new
codegen option that allows choosing different relocation-model. The
available models are:
- default (Use the target-specific default model)
- static
- pic
- no-pic
For a more detailed information use `llc --help`
Closes#13285 (rustc: Stop using LLVMGetSectionName)
Closes#13280 (std: override clone_from for Vec.)
Closes#13277 (serialize: add a few missing pubs to base64)
Closes#13275 (Add and remove some ignore-win32 flags)
Closes#13273 (Removed managed boxes from libarena.)
Closes#13270 (Minor copy-editing for the tutorial)
Closes#13267 (fix Option<~ZeroSizeType>)
Closes#13265 (Update emacs mode to support new `#![inner(attribute)]` syntax.)
Closes#13263 (syntax: Remove AbiSet, use one Abi)
This performs a few touch-ups to the OSX installer:
* A rust logo is shown during installation
* The installation happens to /usr/local by default (instead of /)
* A new welcome screen is shown that's slightly more relevant
This performs a few touch-ups to the OSX installer:
* A rust logo is shown during installation
* The installation happens to /usr/local by default (instead of /)
* A new welcome screen is shown that's slightly more relevant
Summary:
So far, we've used the term POD "Plain Old Data" to refer to types that
can be safely copied. However, this term is not consistent with the
other built-in bounds that use verbs instead. This patch renames the Pod
kind into Copy.
RFC: 0003-opt-in-builtin-traits
Test Plan: make check
Reviewers: cmr
Differential Revision: http://phabricator.octayn.net/D3
Several things here:
* Cleanup
* Fix build targets for building .pkg so that it works and works for all hosts
* Adds support for nightly artifacts
* Put docs in a location suitable for upload to s3 during 'make dist'
* Add coverage of unix binary installers to 'distcheck'
* Fix 'distcheck'
* Change 'dist' to build source tarballs, binary tarballs and OS X packages
This commit shreds all remnants of libextra from the compiler and standard
distribution. Two modules, c_vec/tempfile, were moved into libstd after some
cleanup, and the other modules were moved to separate crates as seen fit.
Closes#8784Closes#12413Closes#12576
The rust-mode-indent-line function had a check, which ran after all the
calculations for how to indent had already happened, that skipped
actually performing the indent if the line was already at the right
indentation.
Because of that, the cursor did not jump to the indentation if the line
wasn't changing. This was particularly annoying if there was nothing
but spaces on the line and you were at the beginning of it--it looked
like the indent just wasn't working.
This removes the check and adds test cases to cover this.
This functionality is not super-core and so doesn't need to be included
in std. It's possible that std may need rand (it does a little bit now,
for io::test) in which case the functionality required could be moved to
a secret hidden module and reexposed by librand.
Unfortunately, using #[deprecated] here is hard: there's too much to
mock to make it feasible, since we have to ensure that programs still
typecheck to reach the linting phase.
- remove `node.js` dep., it has no effect as of #12747 (1)
- switch between LaTeX compilers, some cleanups
- CSS: fixup the print stylesheet, refactor highlighting code (2)
(1): `prep.js` outputs its own HTML directives, which `pandoc` cannot recognize when converting the document into LaTeX (this is why the PDF docs have never been highlighted as of now).
Note that if we were to add the `.rust` class to snippets, we could probably use pandoc's native highlighting capatibilities i.e. Kate ([here is](http://adrientetar.github.io/rust-tuts/tutorial/tutorial.pdf) an example of that).
(2): the only real highlighting change is for lifetimes which are now brown instead of red, the rest is just refactor of twos shades of red that look the same.
Also I made numbers highlighting for src in rustdoc a tint more clear so that it is less bothering.
@alexcrichton, @huonw
Closes#9873. Closes#12788.
`prep.js` outputs its own HTML directives, which `pandoc` cannot
recognize when converting the document into LaTeX (this is why the
PDF docs have never been highlighted as of now).
Note that if we were to add the `.rust` class to snippets, we could
probably use pandoc's native highlighting capatibilities i.e. Kate.
This converts it to be very similar to crates.mk, with a single list of
the documentation items creating all the necessary bits and pieces.
Changes include:
- rustdoc is used to render HTML & test standalone docs
- documentation building now obeys NO_REBUILD=1
- testing standalone docs now obeys NO_REBUILD=1
- L10N is slightly less broken (in particular, it shares dependencies
and code with the rest of the code)
- PDFs can be built for all documentation items, not just tutorial and
manual
- removes the obsolete & unused extract-tests.py script
- adjust the CSS for standalone docs to use the rustdoc syntax
highlighting
The incompatibility of rust-mode with global-whitespace-mode warned
about in the README was actually fixed by commit 581b3db3b3. Remove the
warning from the README and close#3994.
The incompatibility of rust-mode with global-whitespace-mode warned
about in the README was actually fixed by commit 581b3db3b3. Remove the
warning from the README and close#3994.
This commit let librustc automatically pickup LDFLAGS dependencies
inherited from LLVM, which may otherwise result in undefined
references to external symbols under certain linking environment.
A symptom of this issue is eg. a failure when trying to link against
librustc (due to unresolved ffi_*i symbols), while using a system-wide
LLVM.
Signed-off-by: Luca Bruno <lucab@debian.org>
Before it would only catch lines starting `fn` or `pub fn`.
Now it can cope with:
- attributes (e.g. `#[test] fn`)
- external functions (e.g. `extern fn`, `extern "C" fn`)
- unsafe functions (e.g. `unsafe fn`)
… and any correct combination of these
(e.g. `#[test] extern "C" unsafe fn`).
(Expressed another way: make `[[` et al. work with the curly brace at
the end of a line as is standard Rust style, not just at the start is it
is by default in Vim, from K&R style.)
This came out of #11492, where a simpler but less effective technique
was initially proposed; some discussion of the techniques, ways and
means can be found there.
There are still a few caveats:
- Operator-pending mode behaves differently to the standard behaviour:
if inside curly braces, it should delete up to and including the
closing of the outermost curly brace (that doesn't seem to me
consistent with documented behaviour, but it's what it does). Actual
behaviour (the more logical and consistent, in my opinion): up to the
start of the next outermost curly brace.
- With folding enabled (`set fdm=syntax`), `[[` and `]]` do not behave
as they should: the default behaviour treats an entire closed fold as
one line for these purposes while this code does not (I explicitly
`set nofoldenable` in the function—the side-effects are worse with
folds enabled), leading to unexpected behaviour, the worst of which is
`[[` and/or `]]` not working in visual mode on a closed fold (visual
mode keeps it at the extreme end of the region line of the folded
region, so it's always going back to the opening line of that fold and
immediately being shoved back to the end by visual mode).
- `[[` and `]]` are operating inside comments, whereas the standard
behaviour skips comments.
- The viewport position is sometimes changed when it should not be
necessary.
Just like the bare keyword `crate` is highlighted as Error (a little
dubious, actually, given macros), `mod` is invalid after `extern`: it's
obsolete syntax.
I've added details in the description of each comment as to what it does, which I won't redundantly repeat here in the PR. They all relate to indentation in the emacs rust-mode.
What I will note here is that this closes#8787. It addresses the last remaining case (not in the original issue description but in a comment), of indenting `match` statements. With the changes here, I believe every problem described in the issue description or comments of #8787 is addressed.
Don't try to match line comments inside of a comment block. That makes
no sense and can highlight differently for people who override their
highlights.
Similarly, don't match a doc-comment inside of a comment block. It
shouldn't be highlighted differently unless it's actually a doc-comment
(and nested comments are obviously not doc comments).
Fixes#12307.
These two containers are indeed collections, so their place is in
libcollections, not in libstd. There will always be a hash map as part of the
standard distribution of Rust, but by moving it out of the standard library it
makes libstd that much more portable to more platforms and environments.
This conveniently also removes the stuttering of 'std::hashmap::HashMap',
although 'collections::HashMap' is only one character shorter.
This changes the indent to calculate positions relative to the enclosing
block (or braced/parenthesized expression), rather than by an absolute
nesting level within the whole file. This allows things like this to
work:
let x =
match expr {
Pattern => ...
}
With the old method, only one level of nesting would be added within the
match braces, so "Pattern" would have ended up aligned with the match.
The other change is that multiple parens/braces on the same line only
increase the indent once. This is a very common case for passing
closures/procs. The absolute nesting method would do this:
spawn(proc() {
// Indented out two indent levels...
})
whereas the code in this commit does this:
spawn(proc() {
// Indented out only one level...
})
This patch merges IterBytes and Hash traits, which clears up the
confusion of using `#[deriving(IterBytes)]` to support hashing.
Instead, it now is much easier to use the new `#[deriving(Hash)]`
for making a type hashable with a stream hash.
Furthermore, it supports custom non-stream-based hashers, such as
if a value's hash was cached in a database.
This does not yet replace the old IterBytes-hash with this new
version.
Work toward #9876.
This adds `prepare.mk`, which is simply a more heavily-parameterized `install.mk`, then uses `prepare` to implement both `install` and the windows installer (`dist`). Smoke tested on both Linux and Windows.
Declare a `type SendStr = MaybeOwned<'static>` to ease readibility of
types that needed the old SendStr behavior.
Implement all the traits for MaybeOwned that SendStr used to implement.
This commit removes the -c, --emit-llvm, -s, --rlib, --dylib, --staticlib,
--lib, and --bin flags from rustc, adding the following flags:
* --emit=[asm,ir,bc,obj,link]
* --crate-type=[dylib,rlib,staticlib,bin,lib]
The -o option has also been redefined to be used for *all* flavors of outputs.
This means that we no longer ignore it for libraries. The --out-dir remains the
same as before.
The new logic for files that rustc emits is as follows:
1. Output types are dictated by the --emit flag. The default value is
--emit=link, and this option can be passed multiple times and have all
options stacked on one another.
2. Crate types are dictated by the --crate-type flag and the #[crate_type]
attribute. The flags can be passed many times and stack with the crate
attribute.
3. If the -o flag is specified, and only one output type is specified, the
output will be emitted at this location. If more than one output type is
specified, then the filename of -o is ignored, and all output goes in the
directory that -o specifies. The -o option always ignores the --out-dir
option.
4. If the --out-dir flag is specified, all output goes in this directory.
5. If -o and --out-dir are both not present, all output goes in the current
directory of the process.
6. When multiple output types are specified, the filestem of all output is the
same as the name of the CrateId (derived from a crate attribute or from the
filestem of the crate file).
Closes#7791Closes#11056Closes#11667
`Times::times` was always a second-class loop because it did not support the `break` and `continue` operations. Its playful appeal (which I liked) was then lost after `do` was disabled for closures. It's time to let this one go.
`Times::times` was always a second-class loop because it did not support the `break` and `continue` operations. Its playful appeal was then lost after `do` was disabled for closures. It's time to let this one go.
I found awkward to have `MutableCloneableVector` and `CloneableIterator` on the one hand, and `CopyableVector` etc. on the other hand.
The concerned traits are:
* `CopyableVector` --> `CloneableVector`
* `OwnedCopyableVector` --> `OwnedCloneableVector`
* `ImmutableCopyableVector` --> `ImmutableCloneableVector`
* `CopyableTuple` --> `CloneableTuple`
This unfortunately changes an error like
error: mismatched types: expected `&&NotClone` but found `&NotClone`
into
error: type `NotClone` does not implement any method in scope named `clone`
I'd forgotten to update them when I changed this a while ago; it now displays error messages linked to the struct/variant field, rather than the `#[deriving(Trait)]` line, for all traits.
This also adds a very large number of autogenerated tests. I can easily remove/tone down that commit if necessary.
Before this commit, rustc looked in `dirname $0`/../lib for libraries
but that doesn't work when rustc is invoked through a symlink.
This commit makes rustc look in `dirname $(readlink $0)`/../lib, i.e.
it first canonicalizes the symlink before walking up the directory tree.
Fixes#3632.
Fixes the following error when executing `make check-lite`:
Traceback (most recent call last):
File "/home/bnoordhuis/src/rust/src/etc/check-summary.py", line 27, in <module>
map(summarise, logfiles)
File "/home/bnoordhuis/src/rust/src/etc/check-summary.py", line 10, in summarise
with open(fname) as fd:
IOError: [Errno 2] No such file or directory: 'tmp/*.log'
The makefiles and the windows installer disagree on the name of this file. In practical terms this change only means that the '-pre' installers will be named 'rust-0.9-pre-install.exe' instead 'rust-0.9-install.exe'.
- don't check for an hardcoded copyright claim year, check the 2 surrounding strings instead
- logic: if either the `//` or `#`-style copyright patterns are found, don't invalidate
- cleanup hardcoded content and streamline the few files with different line breaks
r? @brson
forward-to-word is undefined, and so Emacs would throw errors in
rust-align-to-expr-after-brace. This change yields the expected
behavior discussed in the issue.
Note that this removes a number of run-pass tests which are exercising behavior
of the old runtime. This functionality no longer exists and is thoroughly tested
inside of libgreen and libnative. There isn't really the notion of "starting the
runtime" any more. The major notion now is "bootstrapping the initial task".
Anchoring the keyword as the first non-whitespace on a line may mean
that the occasional genuine-but-unconventionally-formatted tag is
missed, but it avoids a large number of false positives.
I changed the type descriptive texts about a bit too. That part's purely
cosmetic.
I also changed the ignored file list to use a filename matching the make
rule, `TAGS.vi` instead of `TAGS.vim`.
Anchoring the keyword as the first non-whitespace on a line may mean
that the occasional genuine-but-unconventionally-formatted tag is
missed, but it avoids a large number of false positives.
I changed the type descriptive texts about a bit too. That part's purely
cosmetic.
I also changed the ignored file list to use a filename matching the make
rule, `TAGS.vi` instead of `TAGS.vim`.
llvm supports both win32 native threads and pthread,
but configure tries to find pthread first.
This manually disables pthread to use native api.
This removes libpthreads-2.dll dependency on librustc.
### Remove {As,Into,To}{Option,Either,Result} traits.
Expanded, that is:
- `AsOption`
- `IntoOption`
- `ToOption`
- `AsEither`
- `IntoEither`
- `ToEither`
- `AsResult`
- `IntoResult`
- `ToResult`
These were defined for each other but never *used* anywhere. They are
all trivial and so removal will have negligible effect upon anyone.
`Either` has fallen out of favour (and its implementation of these
traits of dubious semantics), `Option<T>` → `Result<T, ()>` was never
really useful and `Result<T, E>` → `Option<T>` should now be done with
`Result.ok()` (mirrored with `Result.err()` for even more usefulness).
In summary, there's really no point in any of these remaining.
### Rename To{Str,Bytes}Consume traits to Into*.
That is:
- `ToStrConsume` → `IntoStr`;
- `ToBytesConsume` → `IntoBytes`.
rustdoc:
- fix search-bar layout
doc: CSS:
- switch to native pandoc toc depth
- rm some dead code
- clamp width to be readable (we're not Wikipedia!)
- don't background-color titles, it's bloating
- make syntax-highlighting colors inline with rust-lang.org
- space indents
@alexcrichton
### Fix up float highlighting in Vim.
This fixes a regression introduced in #10793.
Having a colorscheme which highlights Float the same as Number (I
believe most do), I hadn't noticed that having the special case of "5."
floats (which was one of the added features in #10793) last made it take
precedence, and so it was left to @thestinger to notice it.
The regression meant that in `5.0`, the `5.` was a `rustFloat` (linked
by default to `Float`) and the `0` was a `rustDecNumber` (linked by
default to `Number`), and for `5.0f32` the `5.` was a `rustFloat` and
the `0f32` was a second `rustFloat` (and thus appeared correctly, though
for the wrong reason).
### Vim keyword highlighting improvements.
- Removed the `log` keyword;
- Removed keyword duplicates;
- Highlighted `const` as `Error` rather than `StorageClass`; and
- Highlighted all the reserved keywords as `Error` rather than as
`Keyword`.
(As usual, these highlightings can be overridden if desired.)
This replaces the link meta attributes with a pkgid attribute and uses a hash
of this as the crate hash. This makes the crate hash computable by things
other than the Rust compiler. It also switches the hash function ot SHA1 since
that is much more likely to be available in shell, Python, etc than SipHash.
Fixes#10188, #8523.
This replaces the link meta attributes with a pkgid attribute and uses a hash
of this as the crate hash. This makes the crate hash computable by things
other than the Rust compiler. It also switches the hash function ot SHA1 since
that is much more likely to be available in shell, Python, etc than SipHash.
Fixes#10188, #8523.
- Removed the `log` keyword;
- Removed keyword duplicates;
- Highlighted `const` as `Error` rather than `StorageClass`; and
- Highlighted all the reserved keywords as `Error` rather than as
`Keyword`.
(As usual, these highlightings can be overridden if desired.)
This fixes a regression introduced in #10793.
Having a colorscheme which highlights Float the same as Number (I
believe most do), I hadn't noticed that having the special case of "5."
floats (which was one of the added features in #10793) last made it take
precedence, and so it was left to @thestinger to notice it.
The regression meant that in `5.0`, the `5.` was a `rustFloat` (linked
by default to `Float`) and the `0` was a `rustDecNumber` (linked by
default to `Number`), and for `5.0f32` the `5.` was a `rustFloat` and
the `0f32` was a second `rustFloat` (and thus appeared correctly, though
for the wrong reason).
Specifically, we can now use:
+ beginning-of-defun
+ end-of-defun
+ mark-defun
where "defun" means a Rust item.
+ Add tests in rust-mode-tests.el
+ Fix indentation in rust-mode-tests.el
+ Add support for trait to Imenu
In order to keep up to date with changes to the libraries that `llvm-config`
spits out, the dependencies to the LLVM are a dynamically generated rust file.
This file is now automatically updated whenever LLVM is updated to get kept
up-to-date.
At the same time, this cleans out some old cruft which isn't necessary in the
makefiles in terms of dependencies.
Closes#10745Closes#10744
- Implement comment nesting (the implementation is quite ugly at present
and is not quite correct; note the big comment in that area).
- Highlight invalid escape sequences as errors.
- Fix up various inconsistencies and incorrectnesses in number
highlighting.
- Update prelude items (``std::io::{Buffer, Writer, Reader, Seek}``).
- Highlight the ``proc`` keyword.
- Remove %-formatting sequence highlighting (a relic of old formatting).
- Don't highlight TODO in strings (it's unconventional).
This infrastructure is meant to support runnings tests that involve various
interesting interdependencies about the types of crates being linked or possibly
interacting with C libraries. The goal of these make tests is to not restrict
them to a particular test runner, but allow each test to run its own tests.
To this end, there is a new src/test/run-make directory which has sub-folders of
tests. Each test requires a `Makefile`, and running the tests constitues simply
running `make` inside the directory. The new target is `check-stageN-rmake`.
These tests will have the destination directory (as TMPDIR) and the local rust
compiler (as RUSTC) passed along to them. There is also some helpful
cross-platform utilities included in src/test/run-make/tools.mk to aid with
compiling C programs and running them.
The impetus for adding this new test suite is to allow various interesting forms
of testing rust linkage. All of the tests initially added are various flavors of
compiling Rust and C with one another as well as just making sure that rust
linkage works in general.
Closes#10434
This commit alters the build process of the compiler to build a static
librustrt.a instead of a dynamic version. This means that we can stop
distributing librustrt as well as default linking against it in the compiler.
This also means that if you attempt to build rust code without libstd, it will
no longer work if there are any landing pads in play. The reason for this is
that LLVM and rustc will emit calls to the various upcalls in librustrt used to
manage exception handling. In theory we could split librustrt into librustrt and
librustupcall. We would then distribute librustupcall and link to it for all
programs using landing pads, but I would rather see just one librustrt artifact
and simplify the build process.
The major benefit of doing this is that building a static rust library for use
in embedded situations all of a sudden just became a whole lot more feasible.
Closes#3361
Previously, `//// foo` and `/*** foo ***/` were accepted as doc comments. This
changes that, so that only `/// foo` and `/** foo ***/` are accepted. This
confuses many newcomers and it seems weird.
Also update the manual for these changes, and modernify the EBNF for comments.
Closes#10638
