- 05 10月, 2018 1 次提交
-
-
由 Oliver Schneider 提交于
-
- 31 8月, 2018 1 次提交
-
-
由 Oliver Schneider 提交于
-
- 07 5月, 2016 2 次提交
-
-
由 Niko Matsakis 提交于
For legacy reasons (presumably), Windows does not permit files name aux.
-
由 Niko Matsakis 提交于
Instead of finding aux-build files in `auxiliary`, we now search for an `aux` directory relative to the test. So if your test is `compile-fail/foo.rs`, we would look in `compile-fail/aux`. Similarly, we ignore the `aux` directory when searching for tets.
-
- 26 3月, 2016 1 次提交
-
-
由 Michael Woerister 提交于
Make the compiler emit an error if the crate graph contains two crates with the same crate-name and crate-salt but different SVHs.
-
- 20 11月, 2015 1 次提交
-
-
由 mitaa 提交于
-
- 08 4月, 2015 1 次提交
-
-
由 Alex Crichton 提交于
This change is aimed at improving cross-crate (inlined) notation of generic closures. The change modifies `simplify::where_predicates` to handle parenthesized notation as well as starting to handle supertrait bounds as well. This was necessary because all output constraints of closures are bound to `FnOnce` but most trait bounds are that of `FnMut`. Close #21801
-
- 01 4月, 2015 1 次提交
-
-
由 Niko Matsakis 提交于
-
- 27 1月, 2015 1 次提交
-
-
由 Brian Anderson 提交于
-
- 22 1月, 2015 1 次提交
-
-
由 Marvin Löbel 提交于
-
- 17 1月, 2015 1 次提交
-
-
由 Alex Crichton 提交于
With the addition of separate search paths to the compiler, it was intended that applications such as Cargo could require a `--extern` flag per `extern crate` directive in the source. The system can currently be subverted, however, due to the `existing_match()` logic in the crate loader. When loading crates we first attempt to match an `extern crate` directive against all previously loaded crates to avoid reading metadata twice. This "hit the cache if possible" step was erroneously leaking crates across the search path boundaries, however. For example: extern crate b; extern crate a; If `b` depends on `a`, then it will load crate `a` when the `extern crate b` directive is being processed. When the compiler reaches `extern crate a` it will use the previously loaded version no matter what. If the compiler was not invoked with `-L crate=path/to/a`, it will still succeed. This behavior is allowing `extern crate` declarations in Cargo without a corresponding declaration in the manifest of a dependency, which is considered a bug. This commit fixes this problem by keeping track of the origin search path for a crate. Crates loaded from the dependency search path are not candidates for crates which are loaded from the crate search path. As a result of this fix, this is a likely a breaking change for a number of Cargo packages. If the compiler starts informing that a crate can no longer be found, it likely means that the dependency was forgotten in your Cargo.toml. [breaking-change]
-
- 05 1月, 2015 1 次提交
-
-
由 Huon Wilson 提交于
-
- 02 1月, 2015 1 次提交
-
-
由 Jorge Aparicio 提交于
Closes #17732 Closes #18819 Closes #19479 Closes #19631 Closes #19632 Closes #19850 Closes #19883 Closes #20005 Closes #20009 Closes #20389
-
- 25 8月, 2014 1 次提交
-
-
由 Alex Crichton 提交于
The privacy pass of the compiler was previously not taking into account the privacy of foreign items, or bindings to external functions. This commit fixes this oversight by encoding the visibility of foreign items into the metadata for each crate. Any code relying on this will start to fail to compile and the bindings must be marked with `pub` to indicate that they can be used externally. Closes #16725 [breaking-change]
-
- 16 5月, 2014 1 次提交
-
-
由 Felix S. Klock II 提交于
Each test works by rendering the flowgraph for the last identified block we see in expanded pretty-printed output, and comparing it (via `diff`) against a checked in "foo.dot-expected.dot" file. Each test post-processes the output to remove NodeIds ` (id=NUM)` so that the expected output is somewhat stable (or at least independent of how we assign NodeIds) and easier for a human to interpret when looking at the expected output file itself. ---- Test writing style notes: I usually tried to write the tests in a way that would avoid duplicate labels in the output rendered flow graph, when possible. The tests that have string literals "unreachable" in the program text are deliberately written that way to remind the reader that the unreachable nodes in the resulting graph are not an error in the control flow computation, but rather a natural consequence of its construction.
-
- 07 4月, 2014 1 次提交
-
-
由 Alex Crichton 提交于
-
- 21 3月, 2014 2 次提交
-
-
由 Alex Crichton 提交于
-
由 Daniel Fagnan 提交于
Signed-off-by: NDaniel Fagnan <dnfagnan@gmail.com>
-
- 08 2月, 2014 1 次提交
-
-
由 Derek Guenther 提交于
-
- 23 12月, 2013 1 次提交
-
-
由 Andreas Neuhaus 提交于
-
- 13 12月, 2013 1 次提交
-
-
由 Jack Moffitt 提交于
-
- 30 11月, 2013 1 次提交
-
-
由 Alex Crichton 提交于
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
-