this makes sure the checks run before typeck (which might use the constant or const
function to calculate an array length) and gives prettier error messages in case of for
loops and such (since they aren't expanded yet).
fixes#30887
r? @pnkfelix
This aligns with unicode recommendations and should be stable for all future
unicode releases. See http://unicode.org/reports/tr31/#R3.
This renames `libsyntax::lexer::is_whitespace` to `is_pattern_whitespace`
so potentially breaks users of libsyntax.
this makes sure the checks run before typeck (which might use the constant or const
function to calculate an array length) and gives prettier error messages in case of for
loops and such (since they aren't expanded yet).
Use arena allocation instead of reference counting for `Module`s to fix memory leaks from `Rc` cycles.
A module references its module children and its import resolutions, and an import resolution references the module defining the imported name, so there is a cycle whenever a module imports something from an ancestor module.
For example,
```rust
mod foo { // `foo` references `bar`.
fn baz() {}
mod bar { // `bar` references the import.
use foo::baz; // The import references `foo`.
}
}
```
I also re-enabled the use of `#[thread_local]` on AArch64. It was originally disabled in the PR that introduced AArch64 (#19790), but the reasons for this were not explained. `#[thread_local]` seems to work fine in my tests on AArch64, so I don't think this should be an issue.
cc @alexcrichton @akiss77
This mixes in additional information into the hash that is
passed to -C extra-filename. It can be used to further distinguish
the standard libraries if they must be installed next to each
other.
Closes#29559
Frankly, I'm not sure if this solves a real problem. It's meant to help with side-by-side and overlapping installations where there are two sets of libs in /usr, but there are other potential issues there as well, including that some of our artifacts don't use this extra-filename munging, and it's not something our installers can support at all.
cc @jauhien Do you still think this helps the Gentoo case?
Since `darwin` is really `apple-darwin`, the valgrind-rpass tests were not actually being run with valgrind on mac before. Also, the `HOST` check was completely wrong.
r? @alexcrichton
This mixes in additional information into the hash that is
passed to -C extra-filename. It can be used to further distinguish
the standard libraries if they must be installed next to each
other.
Closes#29559
It's been awhile since we last updated jemalloc, and there's likely some bugs
that have been fixed since the last version we're using, so let's try to update
again.
It's been awhile since we last updated jemalloc, and there's likely some bugs
that have been fixed since the last version we're using, so let's try to update
again.
this PR reverts previous ones, that tried to make `cc` to found `estdc++` in `/usr/local/lib`. It causes more trouble than it resolvs things: rustc become unbuildable if another version already exists in `/usr/local` (for example, `libstd-xxxx.so` is found in `/usr/local/lib` and in builddir).
so this PR tries another way to achieve build, but using the good linker for building. By default, rustc use `cc` for linking. But under OpenBSD, `cc` is gcc 4.2.1 from base, whereas we build with gcc 4.9 from ports. By linking using the compiler found at compile-time, we ensure that the compiler will found his own stdc++ library without trouble.
r? @alexcrichton
By default, rustc use `cc` as linker. Under OpenBSD, `cc` is gcc version 4.2.1.
So use the compiler found at configure-time for linking: it will be gcc 4.9.
It permits to resolv problem of finding -lestdc++ or -lgcc. For base gcc (4.2), there are in not standard path, whereas for ports gcc (4.9) there are in standard path.
It looks like #27937 accidentally switched the llvmdeps file from the target to
the host by accident, so be sure to use the right llvmdeps file which is built
for the target when building rustc_llvm
This handles cases when the LLVM used isn't configured will the 'usual' targets. Also, cases where LLVM is shared are also handled (ie with `LD_LIBRARY_PATH` etc).
This handles cases when the LLVM used isn't configured will the 'usual'
targets. Also, cases where LLVM is shared are also handled (ie with
`LD_LIBRARY_PATH` etc).
With this commit, metadata encoding and decoding can make use of thread-local encoding and decoding contexts. These allow implementers of `serialize::Encodable` and `Decodable` to access information and
datastructures that would otherwise not be available to them. For example, we can automatically translate def-id and span information during decoding because the decoding context knows which crate the data is decoded from. Or it allows to make `ty::Ty` decodable because the context has access to the `ty::ctxt` that is needed for creating `ty::Ty` instances.
Some notes:
- `tls::with_encoding_context()` and `tls::with_decoding_context()` (as opposed to their unsafe versions) try to prevent the TLS data getting out-of-sync by making sure that the encoder/decoder passed in is actually the same as the one stored in the context. This should prevent accidentally reading from the wrong decoder.
- There are no real tests in this PR. I had a unit tests for some of the core aspects of the TLS implementation but it was kind of brittle, a lot of code for mocking `ty::ctxt`, `crate_metadata`, etc and did actually test not so much. The code will soon be tested by the first incremental compilation auto-tests that rely on MIR being properly serialized. However, if people think that some tests should be added before this can land, I'll try to provide some that make sense.
r? @nikomatsakis
With this commit, metadata encoding and decoding can make use of
thread-local encoding and decoding contexts. These allow implementers
of serialize::Encodable and Decodable to access information and
datastructures that would otherwise not be available to them. For
example, we can automatically translate def-id and span information
during decoding because the decoding context knows which crate the
data is decoded from. Or it allows to make ty::Ty decodable because
the context has access to the ty::ctxt that is needed for creating
ty::Ty instances.
The `rsbegin.o` and `rsend.o` build products should not be generated
on non WinGnu platforms.
This is another path to resolving #30063 for non win-gnu targets.
(And it won't require a snapshot, unlike PR #30208.)
r? @alexcrichton
The `rsbegin.o` and `rsend.o` build products should not be generated
on non WinGnu platforms.
This is another path to resolving #30063 for non win-gnu targets.
(And it won't require a snapshot, unlike PR #30208.)
In #29932, I moved the location of TRPL, but I missed making the changes
in mk/tests.mk. This led to #30088 landing with a broken example.
As such, #30113 will need to land before this.
Previously the file was not regenrated upon modification of `src/rustllvm` or others.
Now it will be rebuilt if `src/llvm` or `src/rustllvm` is touched.
Also added *.rs rule to 'clean' rule so that it is removed upon 'make
clean'.
Fixes#28614.
Debian wants to build all binaries with particular hardening flags.
The Rust makefiles are inconsistent in which architectures they
correctly include CFLAGS/etc from the enivoronment (see mk/cfg/*).
This patch adds LDFLAGS, and then unconditionally prepends
CFLAGS/LDFLAGS/etc to the build commands.
The book was located under 'src/doc/trpl' because originally, it was
going to be hosted under that URL. Late in the game, before 1.0, we
decided that /book was a better one, so we changed the output, but
not the input. This causes confusion for no good reason. So we'll change
the source directory to look like the output directory, like for every
other thing in src/doc.
Rather than modifying the installer to disable directory rewriting,
this patch modifies the directory structure passed to the installer so
that the rewriting gives the correct results. This means that if a
non-standard --libdir is passed to configure then the same --libdir
option (relative to the --prefix) must be passed to the install
script. In the `make install` case this is handled automatically.
Binary distributions are generally generated using the default
--libdir and then have paths optionally rewritten by the installer,
which should continue to work.
This has the advantage of not complicating the installer interface
intended for end-user use.
Fixes#29561
On distros that use i486 or i586 in their CHOST, Rust will fail to build
because it is not handling i486 or i586 like i686 is handled. This
changes the match to do work for all instances of i?86 instead of just
i686. The Yocto Project still uses i586 as a target.
Signed-off-by: Doug Goldstein <cardoe@cardoe.com>
under openbsd, the library path of libstdc++ need to be explicit (due
to the fact the default linker `cc` is gcc-4.2, and not gcc-4.9).
but when a recent LLVM is installed, rustc compilation pikes the bad
LLVM version (which live in /usr/local/lib, which is same directory of
libestdc++.so for gcc-4.9).
this patch move the libstdc++ path from RUST_FLAGS_<target> to special
variable, and use it *after* LLVM_LIBDIR_RUSTFLAGS_<target> in
arguments.
r? @alexcrichton
Rather than modifying the installer to disable directory rewriting,
this patch modifies the directory structure passed to the installer so
that the rewriting gives the correct results. This means that if a
non-standard --libdir is passed to configure then the same --libdir
option (relative to the --prefix) must be passed to the install
script. In the `make install` case this is handled automatically.
Binary distributions are generally generated using the default
--libdir and then have paths optionally rewritten by the installer,
which should continue to work.
This has the advantage of not complicating the installer interface
intended for end-user use.
Fixes#29561
On distros that use i486 or i586 in their CHOST, Rust will fail to build
because it is not handling i486 or i586 like i686 is handled. This
changes the match to do work for all instances of i?86 instead of just
i686. The Yocto Project still uses i586 as a target.
Signed-off-by: Doug Goldstein <cardoe@cardoe.com>
I noticed the nomicon was not listed!
I also removed links to racer and rustfmt since they were not *doc-specific* links, just links to tools, as well as pointed the cargo link directly at the docs.
Removed all the community stuff. There are lots of other places to find this now, including the website.
With pending website changes this page will continue to be pared back, reflecting only what's in-tree, not general Rust docs.
r? @steveklabnik
This should get `--libdir` working as well as it was a couple of weeks ago. (That is, it still rewrites paths incorrectly but it no longer fails during `make install`.)
Fixesgentoo/gentoo-rust#28 and gentoo/gentoo-rust#29.
This is to handle the case where CFG_LIBDIR is not a direct child of
CFG_PREFIX (in other words, where CFG_LIBDIR_RELATIVE has more than
one component).
Emacs warns that makefile lines that start with spaces followed by
tabs are "suspicious". These were harmless since they were
continuation lines, but getting rid of the warning is nice and this
version looks better.
The important one is $(MAKE). make handles recipes containing the
literal string "$(MAKE)" specially, so it is important to make sure it
isn't evaluated until recipe invocation time.
under openbsd, the library path of libstdc++ need to be explicit (due
to the fact the default linker `cc` is gcc-4.2, and not gcc-4.9).
but when a recent LLVM is installed, rustc compilation pikes the bad
LLVM version (which live in /usr/local/lib, which is same directory of
libestdc++.so for gcc-4.9).
this patch move the libstdc++ path from RUST_FLAGS_<target> to special
variable, and use it *after* LLVM_LIBDIR_RUSTFLAGS_<target> in
arguments.
Quite a bit of cruft in the valgrind suppressions. I started from a clean slate and found a few unique failures; this commit also moves the tests "fixed" by these suppressions into run-pass-valgrind.
* Delete `sys::unix::{c, sync}` as these are now all folded into libc itself
* Update all references to use `libc` as a result.
* Update all references to the new flat namespace.
* Moves all windows bindings into sys::c
According to a recent [discussion on IRC](https://botbot.me/mozilla/rust-tools/2015-10-27/?msg=52887517&page=2), there's no good reason for Windows builds to store target libraries under `bin`, when on every other platform they are under `lib`.
This might be a [breaking-change] for some users. I am pretty sure VisualRust has that path hard-coded somewhere.
r? @brson
Note: for now, this change only affects `-windows-gnu` builds.
So why was this `libgcc` dylib dependency needed in the first place?
The stack unwinder needs to know about locations of unwind tables of all the modules loaded in the current process. The easiest portable way of achieving this is to have each module register itself with the unwinder when loaded into the process. All modules compiled by GCC do this by calling the __register_frame_info() in their startup code (that's `crtbegin.o` and `crtend.o`, which are automatically linked into any gcc output).
Another important piece is that there should be only one copy of the unwinder (and thus unwind tables registry) in the process. This pretty much means that the unwinder must be in a shared library (unless everything is statically linked).
Now, Rust compiler tries very hard to make sure that any given Rust crate appears in the final output just once. So if we link the unwinder statically to one of Rust's crates, everything should be fine.
Unfortunately, GCC startup objects are built under assumption that `libgcc` is the one true place for the unwind info registry, so I couldn't find any better way than to replace them. So out go `crtbegin`/`crtend`, in come `rsbegin`/`rsend`!
A side benefit of this change is that rustc is now more in control of the command line that goes to the linker, so we could stop using `gcc` as the linker driver and just invoke `ld` directly.
Previously the file was not regenrated upon modification of src/rustllvm or others.
Now it will be rebuilt if `src/llvm` or `src/rustllvm` is touched.
Also added *.rs rule to 'clean' rule so that it is removed upon 'make
clean'.
It looks like the target libs aren't actually the same across hosts so instead
of always packaging the target libs from CFG_BUILD take the target libs from the
host if we have them and then only failing that do we take them from CFG_BUILD.
Closes#29228
This commit splits out the standard library from the current 'rustc' package
into a new 'rust-std' package. This is the basis for the work on easily
packaging compilers that can cross-compile to new targets.
Since it isn't possible to disable linkage of just GCC startup objects, we now need logic for finding libc installation directory and copying the required startup files (e.g. crt2.o) to rustlib directory.
Bonus change: use the `-nodefaultlibs` flag on Windows, thus paving the way to direct linker invocation.
* Don't pass `-mno-compact-eh`, apparently not all compilers have this?
* Don't pass `+o32`, apparently LLVm doesn't recognize this
* Use `mipsel-linux-gnu` as a prefix instead of `mipsel-unknown-linux-gnu`, this
matches the ubuntu package at least!
This commit splits out the standard library from the current 'rustc' package
into a new 'rust-std' package. This is the basis for the work on easily
packaging compilers that can cross-compile to new targets.
For most parts, rumprun currently looks like NetBSD, as they share the same
libc and drivers. However, being a unikernel, rumprun does not support
process management, signals or virtual memory, so related functions
might fail at runtime. Stack guards are disabled exactly for this reason.
Code for rumprun is always cross-compiled, it uses always static
linking and needs a custom linker.
We don't actually probe for javac in all circumstances, so if you have
javac installed, but don't have antlr4 installed, and you're on Mac OS
X, then you'll get a message that javac is missing, even though that's
wrong.
To fix this, let's just be a bit more generic in the message, so that
it's the same no matter what part of the lexer tests you're missing.
cc
https://www.reddit.com/r/rust/comments/3m199d/running_make_check_on_the_source_code_says_javac/
These changes introduce the ability to cross-compile working binaries for NetBSD/amd64. Previous support added in PR #26682 shared all its code with the OpenBSD implementation, and was therefore never functional (e.g. linking against non-existing symbols and using wrong type definitions). Nonetheless, the previous patches were a great starting point and made my work significantly easier. 😃
Because there are no stage0 snapshots for NetBSD (yet), I used a cross-compiler for NetBSD 7.0 RC3 and only tested some toy programs (threading and channels, stack guards, a small TCP/IP echo server and some other platform dependent bits). If someone could point me to documentation on how to generate a stage0 snapshot from a cross-compiler I'm happy to run the full test suite.
A few other notes regarding Rust on NetBSD/amd64:
- To preserve binary compatibility, NetBSD introduces new symbols for system call wrappers on breaking ABI changes and keeps the old (legacy) symbols around, see [this documentation](https://www.netbsd.org/docs/internals/en/chap-processes.html#syscalls_master) for some details. I went ahead and modified the `libc` and `std` crate to use the current (renamed) symbols instead of the legacy ones where I found them, but I might have missed some. Notably using the `sigaction` symbol (deprecated in 1998) instead of `__sigaction14` even triggers SIGSYS (bad syscall) on my amd64 setup. I also changed the type definitions to use the most recent version.
- NetBSD's gdb doesn't really support position independent executables, so you might want to turn that off for debugging, see [NetBSD Problem Report #48250](https://gnats.netbsd.org/48250).
- For binaries invoked using a relative path, NetBSD supports `$ORIGIN` only for short `rpath`s (~64 chars or so, I'm told). If running an executable fails with `execname not specified in AUX vector: No such file or directory`, consider invoking the binary using its full absolute path.
By default, the linker in use under OpenBSD is the linker of base, which
don't include /usr/local/lib where libstdc++ of gcc-4.9 lives. We need
to add this directory to linker-path-search (using -L).
Search the path of libstdc++.a, which is a known name (libstdc++.so has
SO_VERSION) in the same directory.
it makes rustc compatible with gcc installation that are using
`--program-transform-name' configure flag (on OpenBSD for example).
- detects at configure the name of stdc++ library on the system
- use the detected name in llvm makefile (with enable-static-stdcpp),
and pass it to mklldeps.py
- generate mklldeps.rs using this detected name
note that CFG_STDCPP_NAME is about stdc++ name, not about libc++. If
using libc++, the default name will be `stdc++', but it won't be used
when linking.
Fix formatting
Remove unused imports
Refactor
Fix msvc build
Fix line lengths
Formatting
Enable backtrace tests
Fix using directive on mac
pwd info
Work-around buildbot PWD bug, and fix libbacktrace configuration
Use alternative to `env -u` which is not supported on bitrig
Disable tests on 32-bit windows gnu
Because 'doc' is a directory, when running `make doc`, you'll see
this:
make: Nothing to be done for `doc'.
By adding a target for `doc` to build `docs`, both work.
Fixes#14705
Because 'doc' is a directory, when running `make doc`, you'll see
this:
make: Nothing to be done for `doc'.
By adding a target for `doc` to build `docs`, both work.
Fixes#14705
This fixes the case where we try to re-build & re-install rust to the
same prefix (without uninstalling) while using an llvm-root that is the
same as the prefix.
Without this, builds like that fail with:
'error: multiple dylib candidates for `std` found'
See https://github.com/jmesmon/meta-rust/issues/6 for some details.
May also be related to #20342.
This commit is an implementation of [RFC 1183][rfc] which allows swapping out
the default allocator on nightly Rust. No new stable surface area should be
added as a part of this commit.
[rfc]: https://github.com/rust-lang/rfcs/pull/1183
Two new attributes have been added to the compiler:
* `#![needs_allocator]` - this is used by liballoc (and likely only liballoc) to
indicate that it requires an allocator crate to be in scope.
* `#![allocator]` - this is a indicator that the crate is an allocator which can
satisfy the `needs_allocator` attribute above.
The ABI of the allocator crate is defined to be a set of symbols that implement
the standard Rust allocation/deallocation functions. The symbols are not
currently checked for exhaustiveness or typechecked. There are also a number of
restrictions on these crates:
* An allocator crate cannot transitively depend on a crate that is flagged as
needing an allocator (e.g. allocator crates can't depend on liballoc).
* There can only be one explicitly linked allocator in a final image.
* If no allocator is explicitly requested one will be injected on behalf of the
compiler. Binaries and Rust dylibs will use jemalloc by default where
available and staticlibs/other dylibs will use the system allocator by
default.
Two allocators are provided by the distribution by default, `alloc_system` and
`alloc_jemalloc` which operate as advertised.
Closes#27389
New enough find on Linux doesn't support "-perm +..." and suggests
using "-perm /..." instead, but that doesn't work on Windows.
Hopefully all platforms are happy with this expanded version.
I don't have access to a Windows development system to test this, so someone needs to verify that this actually works there before merging.
Closes#19981.
Per @steveklabnik's comment [here](https://github.com/rust-lang/cargo/issues/739#issuecomment-130085860), the Pandoc components of the Makefile are no longer used, and as such the corresponding components of the documentation are out of date.
- I've removed the Pandoc (and therefore also LaTeX) elements of the makefile and confirmed that the build proceeds correctly.
- I updated the documentation to reference `rustdoc` and of Pandoc.
r? @steveklabnik
Pretty-printed files sometimes start with #![some_feature], which
looks like a shebang line and confuses Windows builds into thinking
they are executables.
This commit leverages the runtime support for DWARF exception info added
in #27210 to enable unwinding by default on 64-bit MSVC. This also additionally
adds a few minor fixes here and there in the test harness and such to get
`make check` entirely passing on 64-bit MSVC:
* The invocation of `maketest.py` now works with spaces/quotes in CC
* debuginfo tests are disabled on MSVC
* A link error for librustc was hacked around (see #27438)
This commit leverages the runtime support for DWARF exception info added
in #27210 to enable unwinding by default on 64-bit MSVC. This also additionally
adds a few minor fixes here and there in the test harness and such to get
`make check` entirely passing on 64-bit MSVC:
* The invocation of `maketest.py` now works with spaces/quotes in CC
* debuginfo tests are disabled on MSVC
* A link error for librustc was hacked around (see #27438)
I have no idea how bors keeps working without this - I can only assume it's some peculiarity of how windows searches for DLLs.
Without this change, running `make check` on windows will not correctly set PATH to include eg. `x86_64-pc-windows-gnu\stage1\bin\rustlib\x86_64-pc-windows-gnu\lib`, and when it tries to run eg. `stage1/test/stdtest-x86_64-pc-windows-gnu.exe`, it will fail because windows can't find the DLLs on which it relies.
It seems to be just a mistake: when the equivalent was added for the branch that deals with unix-like platforms, the windows branch was left unchanged.
This means that we no longer need to ship the `llvm-ar.exe` binary in the MSVC
distribution, and after a snapshot we can remove a good bit of logic from the
makefiles!
Rust's current compilation model makes it impossible on Windows to generate one
object file with a complete and final set of dllexport annotations. This is
because when an object is generated the compiler doesn't actually know if it
will later be included in a dynamic library or not. The compiler works around
this today by flagging *everything* as dllexport, but this has the drawback of
exposing too much.
Thankfully there are alternate methods of specifying the exported surface area
of a dll on Windows, one of which is passing a `*.def` file to the linker which
lists all public symbols of the dynamic library. This commit removes all
locations that add `dllexport` to LLVM variables and instead dynamically
generates a `*.def` file which is passed to the linker. This file will include
all the public symbols of the current object file as well as all upstream
libraries, and the crucial aspect is that it's only used when generating a
dynamic library. When generating an executable this file isn't generated, so all
the symbols aren't exported from an executable.
To ensure that statically included native libraries are reexported correctly,
the previously added support for the `#[linked_from]` attribute is used to
determine the set of FFI symbols that are exported from a dynamic library, and
this is required to get the compiler to link correctly.
This means that we no longer need to ship the `llvm-ar.exe` binary in the MSVC
distribution, and after a snapshot we can remove a good bit of logic from the
makefiles!
