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.
Configure required git be installed so this should be added to the dependencies list. If it's only required when using git, a note could also be added.
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.
On windows, correctly check for errors when spawning threads, and on both
windows and unix handle the error more gracefully rather than printing an opaque
assertion failure.
Closes#13589
This removes all resizability support for ~[T] vectors in preparation of DST.
The only growable vector remaining is Vec<T>. In summary, the following methods
from ~[T] and various functions were removed. Each method/function has an
equivalent on the Vec type in std::vec unless otherwise stated.
* slice::OwnedCloneableVector
* slice::OwnedEqVector
* slice::append
* slice::append_one
* slice::build (no replacement)
* slice::bytes::push_bytes
* slice::from_elem
* slice::from_fn
* slice::with_capacity
* ~[T].capacity()
* ~[T].clear()
* ~[T].dedup()
* ~[T].extend()
* ~[T].grow()
* ~[T].grow_fn()
* ~[T].grow_set()
* ~[T].insert()
* ~[T].pop()
* ~[T].push()
* ~[T].push_all()
* ~[T].push_all_move()
* ~[T].remove()
* ~[T].reserve()
* ~[T].reserve_additional()
* ~[T].reserve_exect()
* ~[T].retain()
* ~[T].set_len()
* ~[T].shift()
* ~[T].shrink_to_fit()
* ~[T].swap_remove()
* ~[T].truncate()
* ~[T].unshift()
* ~str.clear()
* ~str.set_len()
* ~str.truncate()
Note that no other API changes were made. Existing apis that took or returned
~[T] continue to do so.
[breaking-change]
When reporting "consider removing this semicolon" hint message, the
offending semicolon may come from macro call site instead of macro
itself. Using the more appropriate span makes the hint more helpful.
Closes#13428.
The original text stated that one should only return a unique or managed pointer if you were given one in the first place. This makes it sound as if the function *should* return a unique pointer if it were given a unique pointer. The rest of the section goes on to describe why this is bad, and the example of bad code does exactly what the rule just said to do.
I reworded the original rule into a reference to the more concise rule mentioned at the bottom of the section, which helps add emphasis (a la 'it bears repeating').
Instead of allocating both head and tail nodes for the ends of the node
list, a single node can be allocated and linked circularly instead,
making it act as both the head and the tail of the list at the same
time.
Renamed the methods in Bitv that test all bits to have names that, ehm, "roll off the tongue" a bit more easily. :)
Also added tests for them while at it, since they seemed to be missing.
Syntax-only crates are no longer registered with the cstore, so there's no need
to allocate crate numbers to them. This ends up leaving gaps in the crate
numbering scheme which is not expected in the rest of the compiler.
Closes#13560
The original text stated that one should only return a unique or managed pointer if you were given one in the first place. This makes it sound as if the function *should* return a unique pointer if it were given a unique pointer. The rest of the section goes on to describe why this is bad, and the example of bad code does exactly what the rule just said to do.
I reworded the original rule into a reference to the more concise rule mentioned at the bottom of the section, which helps add emphasis (a la 'it bears repeating').
Fix#12856.
I wanted to put this up first because I wanted to get feedback about the second commit in the series, commit 8599236. Its the more invasive part of the patch and is largely just belt-and-suspenders assertion checking; in the commit message I mentioned at least one other approach we could take here. Or we could drop the belt-and-suspenders and just rely on the guard added in the first patch, commit 8d6a005 (which is really quite trivial on its own).
So any feedback on what would be better is appreciated.
r? @nikomatsakis
This version of `is_to_be_inferred` double-checks the result from
`inferred_map` by querying the `named_region_map` and `ast_map` and
then asserts that the `inferred_map` state is consistent with its own
findings. (See issue 13261 for further discussion of the approaches).
If a linker finds both a static and a dynamic version of the same library, then
the linker often chooses the dynamic version. This is surprising when a native
library is specified as being "static" in rust source. This modifies the linker
command line to obey the hints given in rust source files and instructing the
linker to prefer a particular version of a found library.
Unfortunately, this patch has no effect on osx because the linker supports
no such hint, and it also has no effect on windows because the linker apparently
just ignores it. For now this is predominately used to enable the previous patch
of linking to libstdc++ statically, but more support would need to be added for
this in the future if we wanted to officially support it.
cc #12557 (doesn't close because it doesn't support OSX and windows)
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.
This is the first snapshot build by mingw-w64 with the win32 threading model I believe (Closes#13501).
Curiously, this successfully built a snapshot on freebsd when the auto builder is continuously segfaulting. Who knew!
OSX often has a more recent version of clang than it does for GCC. When an older
version of gcc is detected on OSX, the --enable-clang flag is implicitly
enabled.
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.
This comes with a number of fixes to be compatible with upstream LLVM:
* Previously all monomorphizations of "mem::size_of()" would receive the same
symbol. In the past LLVM would silently rename duplicated symbols, but it
appears to now be dropping the duplicate symbols and functions now. The symbol
names of monomorphized functions are now no longer solely based on the type of
the function, but rather the type and the unique hash for the
monomorphization.
* Split stacks are no longer a global feature controlled by a flag in LLVM.
Instead, they are opt-in on a per-function basis through a function attribute.
The rust #[no_split_stack] attribute will disable this, otherwise all
functions have #[split_stack] attached to them.
* The compare and swap instruction now takes two atomic orderings, one for the
successful case and one for the failure case. LLVM internally has an
implementation of calculating the appropriate failure ordering given a
particular success ordering (previously only a success ordering was
specified), and I copied that into the intrinsic translation so the failure
ordering isn't supplied on a source level for now.
* Minor tweaks to LLVM's API in terms of debuginfo, naming, c++11 conventions,
etc.
structure's Data2 and Data3 members expect WORD types instead of DWORD. I
discovered this discrepancy while experimenting with some bindings to
Microsoft's OLE2 api. The discrepancy was corrupting the contents of the
string returned by UuidToString after I used known GUIDs to test the
accuracy of the function binding. I didn't add test cases because it would
mean adding a dependency to my rather incomplete binding library. However,
the fix produces expected string values when tested.
Closes#13561. All definition lists have been converted to unordered lists. This is a temporary measure; please revert this when Sundown (or any replacement) gets a support for definition lists in the future.
Part of this required added an override of `fold_type_method` in the
Folder for Ctx impl; it follows the same pattern as `fold_method`.
Also, as a drive-by fix, I moved all of the calls to `folder.new_id`
in syntax::fold's no-op default traversal to really be the first
statement in each function.
* This is to uphold the invariant that `folder.new_id` is always
called first (an unfortunate requirement of the current `ast_map`
code), an invariant that we seemingly were breaking in e.g. the
previous `noop_fold_block`.
* Now it should be easier to see when adding new code that this
invariant must be upheld.
* (note that the breakage in `noop_fold_block` may not have mattered
so much previously, since the only thing that blocks can bind are
lifetimes, which I am only adding support for now.)
Before adding a variance constrant for a given early-bound param,
check if it was meant to be inferred.
To support the above, added `fn is_to_be_inferred` to
`variance::ConstraintContext`.
