This commit ceases documentation-by-default of crates such as `term`,
`serialize`, and `alloc`. Crates like `term` and `rand` have duplicates on
`crates.io` and the search index entries generated in the local tree end up
only leading to confusion. Crates like the entire compiler infrastructure,
`flate`, or `rbml` don't need to be documented in such a prominent location.
This change also means that doc tests will no longer be run for crates beyond
the facade (e.g. `serialize` or `term`), but there were very few doc tests in
there to begin with.
Closes#22168
Add a new test directory called 'rustdoc' where all files inside are documented
and run against the `htmldocck` script to have assertions about the output.
Rationale for this, is that I lurked `ulimit -c unlimited` into my .profile to debug an unrelated crash, that I kept forgetting to set before hand. I then ran the test suite and discovered that I had 150 gigs of core dumps in `/cores`.
Very open to another approach, or to setting the limit to something higher than 0, but I think it would be nice if the build system tried to save you from yourself here.
This saves a bunch of a time and will make distributions smaller, as well as
avoiding filling the implementors page with internal garbage. Turn it back on
with `--enable-compiler-docs` if you want them.
(Crates behind the facade are not documented at all)
[breaking-change]
This saves a bunch of a time and will make distributions smaller, as well as
avoiding filling the implementors page with internal garbage. Turn it back on
with `--enable-compiler-docs` if you want compiler docs during development.
Crates behind the facade are only documented on nightly/dev builds (where they
can be used).
[breaking-change]
Closes#23772Closes#21297
The RUST_TARGET_STAGE_N rule uses LLVM_LIBDIR_RUSTFLAGS_<target-triple>,
which expands to -L "$(llvm-config --libdir)" when the target-triple is
also a host-triple. Rather than expand to -L "" if llvm-config has not yet
been built, add a dependency on the target llvm-config.
When the target-triple is not a host-triple, the new LLVM_CONFIG_$(2)
dependency should expand to nothing.
r? alexcrichton
The RUST_TARGET_STAGE_N rule uses LLVM_LIBDIR_RUSTFLAGS_<target-triple>,
which expands to -L "$(llvm-config --libdir)" when the target-triple is
also a host-triple. Rather than expand to -L "" if llvm-config has not yet
been built, add a dependency on the target llvm-config.
When the target-triple is not a host-triple, the new LLVM_CONFIG_$(2)
dependency should expand to nothing.
LLVM_LIBDIR_<triple> is only defined for host triples, not target triples.
FWIW, the same is true for LLVM_STDCPP_RUSTFLAGS_<triple>, where we
explicitly define it as empty when --enable-llvm-static-stdcpp is not
specified, but it's still undefined for cross-compiled triples.
This commit is an implementation of [RFC 563][rfc] which adds a new
`cfg(debug_assertions)` directive which is specially recognized and calculated
by the compiler. The flag is turned off at any optimization level greater than 1
and may also be explicitly controlled through the `-C debug-assertions`
flag.
[rfc]: https://github.com/rust-lang/rfcs/pull/563
The `debug_assert!` and `debug_assert_eq!` macros now respect this instead of
the `ndebug` variable and `ndebug` no longer holds any meaning to the standard
library.
Code which was previously relying on `not(ndebug)` to gate expensive code should
be updated to rely on `debug_assertions` instead.
Closes#22492
[breaking-change]
This commit deprecates the majority of std::old_io::fs in favor of std::fs and
its new functionality. Some functions remain non-deprecated but are now behind a
feature gate called `old_fs`. These functions will be deprecated once
suitable replacements have been implemented.
The compiler has been migrated to new `std::fs` and `std::path` APIs where
appropriate as part of this change.
Strategy: If the end goal is to touch e.g. `stamp.std`, then we first
touch `stamp.std.start_time` before doing anything else. Then when
the receipe finishes, we touch `stamp.std` using the timestamp from
`stamp.std.start_time` as the reference time, and remove
`stamp.std.start_time`.
Fix#6518.
This pulls out the implementations of most built-in lints into a
separate crate, to reduce edit-compile-test iteration times with
librustc_lint and increase parallelism. This should enable lints to be
refactored, added and deleted much more easily as it slashes the
edit-compile cycle to get a minimal working compiler to test with (`make
rustc-stage1`) from
librustc -> librustc_typeck -> ... -> librustc_driver ->
libcore -> ... -> libstd
to
librustc_lint -> librustc_driver -> libcore -> ... libstd
which is significantly faster, mainly due to avoiding the librustc build
itself.
The intention would be to move as much as possible of the infrastructure
into the crate too, but the plumbing is deeply intertwined with librustc
itself at the moment. Also, there are lints for which diagnostics are
registered directly in the compiler code, not in their own crate
traversal, and their definitions have to remain in librustc.
This is a [breaking-change] for direct users of the compiler APIs:
callers of `rustc::session::build_session` or
`rustc::session::build_session_` need to manually call
`rustc_lint::register_builtins` on their return value.
This should make #22206 easier.
After making `rustc` fail on errors at a stop point, like `-Z parse-only`, in #22117, the files in this PR also fail during the parse stage and should be moved as well. Sorry for spliting this move up in two PRs.
- Now "make check-stage2-T-aarch64-linux-android-H-x86_64-unknown-linux-gnu" works (#21773)
- Fix & enable debuginfo tests for android (#10381)
- Fix & enable more tests for android (both for arm/aarch64)
- Enable many already-pass tests on android (both for arm/aarch64)
`cp -a` is a GNU extension. Use an alternate combinaison of POSIX options
(`-PRp`) that do nearly the same.
The difference is `-a` will preserve context, links and xattr attributes,
whereas `-p` not. But as we use it only for copy a file, there is no
difference in the current context.
This is a patch for #22291.
PLEASE_BENCH=1 adds --bench to the arguments passed to the executable to be tested. At the moment, compiletest does not accept a --bench argument, because it is not needed for any test in src/test/, even the tests in src/test/bench do not use #[bench].
I have updated the makefile to only add the --bench flag for crate tests. I do not think that changing compiletest add --bench to the run arguments of all compile tests makes sense, because it would mess up tests which check command line arguments. Also the bench option can be added as comment in a compile test as well.
Highlights:
* Adds an 'uninstall.sh' script to `/usr/local/lib/rustlib/uninstall.sh`, the path to which is printed during installation.
* Components can be deselected during install, like `install.sh --without=rust-docs`.
* Components can be listed with `install.sh --list-components`.
* Vastly reduces spew during install (but supporting a `--verbose` option).
Typicall install run looks like:
```
brian@brianX1:~/dev/multirust⟫ sudo ./install.sh
[sudo] password for brian:
install: creating uninstall script at /usr/local/lib/rustlib/uninstall.sh
install: installing component 'rustc'
install: installing component 'cargo'
install: installing component 'rust-docs'
Rust is ready to roll.
```
Needs to be merged right before corresponding PRs to cargo and rust-packaging.
Fixes https://github.com/rust-lang/rust/issues/21117
Fixes https://github.com/rust-lang/rust/issues/20283
`cp -a` is a GNU extension. Use an alternate combinaison of POSIX options
(`-PRp`) that do nearly the same.
The difference is `-a` will preserve context, links and xattr attributes,
whereas `-p` not. But as we use it only for copy a file, there is no
difference in the current context.
This restructures tidy.py to walk the tree itself,
and improves performance considerably by not loading entire
files into buffers for licenseck.
Splits build rules into 'tidy', 'tidy-basic', 'tidy-binaries',
'tidy-errors', 'tidy-features'.
This adds a new lexer/parser combo for the entire Rust language can be generated with with flex and bison, taken from my project at https://github.com/bleibig/rust-grammar. There is also a testing script that runs the generated parser with all *.rs files in the repository (except for tests in compile-fail or ones that marked as "ignore-test" or "ignore-lexer-test"). If you have flex and bison installed, you can run these tests using the new "check-grammar" make target.
This does not depend on or interact with the existing testing code in the grammar, which only provides and tests a lexer specification.
OS X users should take note that the version of bison that comes with the Xcode toolchain (2.3) is too old to work with this grammar, they need to download and install version 3.0 or later.
The parser builds up an S-expression-based AST, which can be displayed by giving the "-v" argument to parser-lalr (normally it only gives output on error). It is only a rough approximation of what is parsed and doesn't capture every detail and nuance of the program.
Hopefully this should be sufficient for issue #2234, or at least a good starting point.
The regex library was largely used for non-critical aspects of the compiler and
various external tooling. The library at this point is duplicated with its
out-of-tree counterpart and as such imposes a bit of a maintenance overhead as
well as compile time hit for the compiler itself.
The last major user of the regex library is the libtest library, using regexes
for filters when running tests. This removal means that the filtering has gone
back to substring matching rather than using regexes.
Initial support for aarch64-linux-android (#18920)
- Add new configuration files
- Modify some options to compile & link succesfully.
(PIE, disable tls on jemalloc, modify some external function linkage, ..)
- To build, refer to https://github.com/rust-lang/rust/wiki/Doc-building-for-android.
(tested with platform=21 and toolchain=aarch64-linux-android-4.9)
This does the bare minimum to make registration of error codes work again. After this patch, every call to `span_err!` with an error code gets that error code validated against a list in that crate and a new tidy script `errorck.py` validates that no error codes are duplicated globally.
There are further improvements to be made yet, detailed in #19624.
r? @nikomatsakis
Removed use of unused LDPATH variable on Windows as is done for other platforms, and added GCC flag to ensure MINGW's ANSI compatible STDIO functions are used wherever available (required by jemalloc).
Without these changes it ends up setting the PATH twice, and the second time the PATH begins with `:` which is invalid. Also the regular msvcrt printf-like functions would be used which don't understand stuff like %hhd and %z which jemalloc uses.
This change ought not to make any difference to the output but it fixes the build process for me since at least my build environment couldn't handle that broken path caused by LDPATH being empty.
The script is intended as a tool for doing every sort of verifications amenable to Rustdoc's HTML output. For example, link checkers would go to this script. It already parses HTML into a document tree form (with a slight caveat), so future tests can make use of it.
As an example, relevant `rustdoc-*` run-make tests have been updated to use `htmldocck.py` and got their `verify.sh` removed. In the future they may go to a dedicated directory with htmldocck running by default. The detailed explanation of test scripts is provided as a docstring of htmldocck.
cc #19723
The script is intended as a tool for doing every sort of verifications
amenable to Rustdoc's HTML output. For example, link checkers would go
to this script. It already parses HTML into a document tree form (with
a slight caveat), so future tests can make use of it.
As an example, relevant `rustdoc-*` run-make tests have been updated
to use `htmldocck.py` and got their `verify.sh` removed. In the future
they may go to a dedicated directory with htmldocck running by default.
The detailed explanation of test scripts is provided as a docstring of
htmldocck.
cc #19723
In accordance with [collections reform part 2][rfc] this macro has been moved to
an external [bitflags crate][crate] which is [available though
crates.io][cratesio]. Inside the standard distribution the macro has been moved
to a crate called `rustc_bitflags` for current users to continue using.
[rfc]: https://github.com/rust-lang/rfcs/blob/master/text/0509-collections-reform-part-2.md
[crate]: https://github.com/rust-lang/bitflags
[cratesio]: http://crates.io/crates/bitflags
The major user of `bitflags!` in terms of a public-facing possibly-stable API
today is the `FilePermissions` structure inside of `std::io`. This user,
however, will likely no longer use `bitflags!` after I/O reform has landed. To
prevent breaking APIs today, this structure remains as-is.
Current users of the `bitflags!` macro should add this to their `Cargo.toml`:
bitflags = "0.1"
and this to their crate root:
#[macro_use] extern crate bitflags;
Due to the removal of a public macro, this is a:
[breaking-change]
Originally, this was going to be discussed and revisted, however I've been working on this for months, and a rebase on top of master was about 1 flight's worth of work so I just went ahead and did it.
This gets you as far as being able to target powerpc with, eg:
LD_LIBRARY_PATH=./x86_64-unknown-linux-gnu/stage2/lib/ x86_64-unknown-linux-gnu/stage2/bin/rustc -C linker=powerpc-linux-gnu-gcc --target powerpc-unknown-linux-gnu hello.rs
Would really love to get this out before 1.0. r? @alexcrichton
