mikros/rust
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
087a0136d0
rust/tests/run-make-fulldeps/extern-flag-disambiguates/Makefile

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

26 lines
598 B
Makefile
Raw Normal View History

Diagnose missing includes in run-make tests
2022-08-22 19:00:00 -05:00
include ../tools.mk
rustc: Add a flag for specifying dependencies This comit implements a new flag, --extern, which is used to specify where a crate is located. The purpose of this flag is to bypass the normal crate loading/matching of the compiler to point it directly at the right file. This flag takes the form `--extern foo=bar` where `foo` is the name of a crate and `bar` is the location at which to find the crate. Multiple `--extern` directives are allowed with the same crate name to specify the rlib/dylib pair for a crate. It is invalid to specify more than one rlib or more than one dylib, and it's required that the crates are valid rust crates. I have also added some extensive documentation to metadata::loader about how crate loading should work. RFC: 0035-remove-crate-id
2014-07-01 10:37:54 -05:00
# Attempt to build this dependency tree:
#
# A.1 A.2
# |\ |
# | \ |
# B \ C
# \ | /
# \|/
# D
#
# Note that A.1 and A.2 are crates with the same name.
all:
$(RUSTC) -C metadata=1 -C extra-filename=-1 a.rs
$(RUSTC) -C metadata=2 -C extra-filename=-2 a.rs
$(RUSTC) b.rs --extern a=$(TMPDIR)/liba-1.rlib
$(RUSTC) c.rs --extern a=$(TMPDIR)/liba-2.rlib
rustc: Fix a leak in dependency= paths 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]
2015-01-06 10:46:07 -06:00
@echo before
rustc: Add a flag for specifying dependencies This comit implements a new flag, --extern, which is used to specify where a crate is located. The purpose of this flag is to bypass the normal crate loading/matching of the compiler to point it directly at the right file. This flag takes the form `--extern foo=bar` where `foo` is the name of a crate and `bar` is the location at which to find the crate. Multiple `--extern` directives are allowed with the same crate name to specify the rlib/dylib pair for a crate. It is invalid to specify more than one rlib or more than one dylib, and it's required that the crates are valid rust crates. I have also added some extensive documentation to metadata::loader about how crate loading should work. RFC: 0035-remove-crate-id
2014-07-01 10:37:54 -05:00
$(RUSTC) --cfg before d.rs --extern a=$(TMPDIR)/liba-1.rlib
$(call RUN,d)
rustc: Fix a leak in dependency= paths 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]
2015-01-06 10:46:07 -06:00
@echo after
rustc: Add a flag for specifying dependencies This comit implements a new flag, --extern, which is used to specify where a crate is located. The purpose of this flag is to bypass the normal crate loading/matching of the compiler to point it directly at the right file. This flag takes the form `--extern foo=bar` where `foo` is the name of a crate and `bar` is the location at which to find the crate. Multiple `--extern` directives are allowed with the same crate name to specify the rlib/dylib pair for a crate. It is invalid to specify more than one rlib or more than one dylib, and it's required that the crates are valid rust crates. I have also added some extensive documentation to metadata::loader about how crate loading should work. RFC: 0035-remove-crate-id
2014-07-01 10:37:54 -05:00
$(RUSTC) --cfg after d.rs --extern a=$(TMPDIR)/liba-1.rlib
$(call RUN,d)
Reference in New Issue Copy Permalink