Commit graph

46 commits

Author SHA1 Message Date
Eric Huss
0afd943dad Fix some test output validation. 2023-11-15 15:10:18 -08:00
Ed Page
293f2250d6 feat(doc): Print the generated docs links
I've wanted something like this myself.  I dislike using `--open`
because I tend to move up to re-run my `cargo doc` run but then have to
edit it to remove `--open`.
Also makes it annoying when opening docs when `cargo doc` is wrapped by
a tool like `make`.

This was previously attempted in #5592:
- Unlike the request in #5562, this aligns with #5592 in always printing
  rather than using a flag as this seems generally useful
- Unlike #5592, this prints as an alternative to "Opening" to keep
  things light
- Unlike #5592, this prints afterwards as the link is only valid then

Fixes #5562
2023-10-19 10:51:56 -05:00
Deadbeef
43dccc7535 apply suggestions 2023-08-25 01:43:29 +00:00
Deadbeef
b2b34e4ca2 update tests 2023-08-25 01:43:29 +00:00
cassaundra
5554889f88
Include rust-version in publish request
crates.io reads rust-version from the tarball directly, but we can include it in
the publish request for the sake of consistency for third-party registries.
2023-04-26 11:59:29 -07:00
Eric Huss
f60666ca6e Reword published/completed to uploaded/published 2023-03-15 08:15:00 -07:00
Eric Huss
7e4764a56b Add more information to wait-for-publish 2023-03-15 08:15:00 -07:00
bors
524231f43f Auto merge of #11643 - jofas:11260-fix, r=weihanglo
Error message for transitive artifact dependencies with targets the package doesn't directly interact with

Address #11260. Produces an error message like described by `@weihanglo` [here](https://github.com/rust-lang/cargo/issues/11260#issuecomment-1400455203):

```
error: could not find specification for target "x86_64-windows-msvc"
  Dependency `bar v0.1.0` requires to build for target "x86_64-windows-msvc".
```

Note that this is not a complete fix for #11260.
2023-02-25 07:39:08 +00:00
hi-rustin
0b06a456f2 Make blocking tests non blocking 2023-02-23 09:11:52 +08:00
jofas
4bdface19a applying code review to make get_sysroot_target_libdir more readable + incorporated changes into corresponding test 2023-02-06 14:43:44 +01:00
jofas
ef227e401d error message for target specification that couldn't be queried from rustc 2023-01-28 11:08:23 +01:00
jofas
d5e43bb22c added test replicating error encountered with transitive artifact dependencies 2023-01-24 13:08:12 +01:00
jofas
ded1a15a0a removed trailing whitespaces (done automatically by vim) 2023-01-24 12:40:34 +01:00
Dinu Blanovschi
0beb5fe93d Simple explanations for why cargo rebuilds crates 2022-12-28 16:27:50 +01:00
Roman Volosatovs
548b2528fb
test: reproduce bindep dependency collision bug
Signed-off-by: Roman Volosatovs <rvolosatovs@riseup.net>
2022-12-22 16:16:12 +01:00
Roman Volosatovs
6d43fa64ec
refactor: simplify rust-lang#10525 test case
Signed-off-by: Roman Volosatovs <rvolosatovs@riseup.net>
2022-12-22 14:45:25 +01:00
bstrie
386645e990
test: add test for #10525 2022-12-22 14:45:25 +01:00
Roman Volosatovs
4677a7cce5
test: reproduce transitive bindep dependency bug
This is a unit test reproducing the bindep transitive dependency bug based upon examples from
- https://github.com/rust-lang/cargo/issues/10837
- https://github.com/rust-lang/cargo/issues/11463

Signed-off-by: Roman Volosatovs <rvolosatovs@riseup.net>
2022-12-22 14:45:21 +01:00
Weihang Lo
5b8985a470
fix(bindeps): assumed host target and optional = true coexist
`{ …, artifact = "bin", target = "target" }` should also be considered
to being built for `FeaturesFor::ArtifactDep` instead of `NormalOrDev`.

[This line][1] requests for `ArtifactDep` but [here][2] Cargo ignore
assumed host target of artifact dep.

Change it to explicit set host target triple when

- `{ …, target = "target" }`, and
- `--target` is not presented, meaning it would be build on host platform.

[1]: 1382b44e43/src/cargo/core/compiler/unit_dependencies.rs (L887)
[2]: 1382b44e43/src/cargo/core/resolver/features.rs (L857)
2022-12-04 11:43:50 +00:00
Weihang Lo
bf56587e26
fix(bindeps): target field specified and optional = true coexist
> Adapted from #11183

Previously, `is_dep_activated` depends on `activated_dependencies`,
which is a map of `PackageFeaturesKey` to its own activated `DepFeature`s.
`PackageFeaturesKey` in feature resolver is always comprised of

* A `PackageId` of a given dependency, and
* A enum value that helps decoupling activated features for that dependency.
  Currently depending on the type of given dependency.

Looking into issue 10526, it has an `activated_dependencies` of

```
{
    (mycrate, NormalOrDev) -> [dep:mybindep]
}
```

However, this [line][1] accidentally use a parent's `pkgid`
and a dependency's `FeaturesFor` to compose a key:

```
(mycrate, ArtifactDep("x86_64-unknown-linux-gnu"))
```

That is never a valid key to query features for artifacts dependency.
A valid key should be comprised of components both from the parent:

```
(mycrate, NormalOrDev)
```

Or both from the dependency itself:

```
(mybindep, ArtifactDep("x86_64-unknown-linux-gnu"))
```

This `unit_for` is from parent and should already contain its own
artifact dep information inside `artifact_target_for_features`,
so we don't need to map any dependency artifact from `dep.artifact()`.

[1]: a2ea66bea6/src/cargo/core/compiler/unit_dependencies.rs (L1106-L1107)
2022-12-04 11:41:49 +00:00
Weihang Lo
7dcb6daa7d
test(bindeps): assumed host target and optional = true coexist 2022-12-04 11:41:49 +00:00
Weihang Lo
437bed069a
test(bindeps): target field specified and optional = true coexist 2022-12-04 11:41:49 +00:00
Weihang Lo
347523e163
fix(fingerprint): include bin target if it is also an artifact dep 2022-11-09 17:44:17 +00:00
Weihang Lo
58e86d4d94
test(bindeps): recompile when bin target is also artifact dep
This records the WRONG behaviour, which parent fingerpint cannot detect
change of a dependency if it is a bin target and also a artifact dep.
2022-11-09 16:29:15 +00:00
Weihang Lo
5fe27327c3
Revert "Auto merge of #11183 - weihanglo:issue/10526, r=ehuss"
This reverts commit d4c38af120, reversing
changes made to 92d8826ed4.
2022-11-03 15:08:30 +00:00
Anton Lazarev
d70a4ee93c
update stderr in tests for unrelated functionality 2022-10-28 17:13:25 -07:00
bors
d4c38af120 Auto merge of #11183 - weihanglo:issue/10526, r=ehuss
artifact deps shoud works when target field specified coexists with `optional = true`
2022-10-28 00:50:23 +00:00
Weihang Lo
c31e017885
fix(bindeps): target field specified and optional = true coexist
Previously, `is_dep_activated` depends on `activated_dependencies`,
which is a map of `PackageFeaturesKey` to its own activated `DepFeature`s.
`PackageFeaturesKey` in feature resolver is always comprised of

* A `PackageId` of a given dependency, and
* A enum value that helps decoupling activated features for that dependency.
  Currently depending on the type of given dependency.

Looking into issue 10526, it has an `activated_dependencies` of

```
{
    (mycrate, NormalOrDevOrArtifactTarget(None)) -> [dep:mybindep]
}
```

However, this [line][1] accidentally use a parent's `pkgid`
and a dependency's `FeaturesFor` to compose a key:

```
(mycrate, NormalOrDevOrArtifactTarget("x86_64-unknown-linux-gnu"))
```

That is never a valid key to query features for artifacts dependency.
A valid key should be comprised of components both from the parent:

```
(mycrate, NormalOrDevOrArtifactTarget(None))
```

Or both from the dependency itself:

```
(mybindep, NormalOrDevOrArtifactTarget("x86_64-unknown-linux-gnu"))
```

As aforementioned `activated_dependencies` only stores parent packages
and their activated features. Those informations are included in
`activated_features` as well, so this commit goes with the route that
removes `activated_dependencies` and uses only dependency's infomation
to query if itself is activated.

[1]: 0b84a35c2c/src/cargo/core/compiler/unit_dependencies.rs (L1097-L1098)
2022-10-26 20:41:56 +08:00
Weihang Lo
7089bbf2e4
test(bindeps): target field specified and optional = true coexist 2022-10-26 20:41:56 +08:00
Ed Page
f2fc5ca86d fix(publish): Block until it is in index
Originally, crates.io would block on publish requests until the publish
was complete, giving `cargo publish` this behavior by extension.  When
crates.io switched to asynchronous publishing, this intermittently broke
people's workflows when publishing multiple crates.  I say interittent
because it usually works until it doesn't and it is unclear why to the
end user because it will be published by the time they check.  In the
end, callers tend to either put in timeouts (and pray), poll the
server's API, or use `crates-index` crate to poll the index.

This isn't sufficient because
- For any new interested party, this is a pit of failure they'll fall
  into
- crates-index has re-implemented index support incorrectly in the past,
  currently doesn't handle auth, doesn't support `git-cli`, etc.
- None of these previous options work if we were to implement
  workspace-publish support (#1169)
- The new sparse registry might increase the publish times, making the
  delay easier to hit manually
- The new sparse registry goes through CDNs so checking the server's API
  might not be sufficient
- Once the sparse registry is available, crates-index users will find
  out when the package is ready in git but it might not be ready through
  the sparse registry because of CDNs

So now `cargo` will block until it sees the package in the index.
- This is checking via the index instead of server APIs in case there
  are propagation delays.  This has the side effect of being noisy
  because of all of the "Updating index" messages.
- This is done unconditionally because cargo used to block and that
  didn't seem to be a problem, blocking by default is the less error
  prone case, and there doesn't seem to be enough justification for a
  "don't block" flag.

The timeout was 5min but I dropped it to 1m.  Unfortunately, I don't
have data from `cargo-release` to know what a reasonable timeout is, so
going ahead and dropping to 60s and assuming anything more is an outage.

Fixes #9507
2022-10-13 12:56:40 -05:00
Ed Page
33ba607783 refactor(tests): Hack publish to balance testing/wait_for_publish 2022-10-10 13:10:29 -05:00
Arlo Siemsen
dd5134c7a5 Implement RFC 3289: source replacement ambiguity 2022-10-07 22:30:59 -05:00
Scott Schafer
ab18bd40d5 refactor(testsuite): Replace [project] with [package] 2022-09-26 09:51:16 -06:00
Eric Huss
7eb007ddbf Add reasons to all ignored tests. 2022-08-02 12:24:00 -07:00
Scott Schafer
c239e407e7 add a reason to masquerade_as_nightly_cargo so it is searchable 2022-07-15 21:32:23 -05:00
Sebastian Thiel
0b53b1b6d4
Undo a prior change to fix #10452 2022-03-14 11:01:28 +08:00
Sebastian Thiel
92cce52182
reproduce: wrong features in a build script for a shared dependency (#10452) 2022-03-14 10:55:30 +08:00
Sebastian Thiel
4e847a2c11
Remove prior hack and replace it with a proper solution
This is the diff from
https://github.com/rust-lang/cargo/pull/10433#issuecomment-1064577586
applied to the codebase with the previous hack removed.

Thanks a million to @ehuss who has the insight to find fixes like this.
2022-03-14 10:24:55 +08:00
Sebastian Thiel
0bede7331f
A cry for help with a fix for the issue that looks like a hack.
In order not to give up and create a basis for discussion while ending
my 3h oddisey on finding a fix for today, I present something that
seems to work even though I hope there are better ways to solve this.
2022-03-01 15:18:14 +08:00
Sebastian Thiel
9ede09a1c8
trigger another failure by using [target.'cfg(…)'.dependencies] syntax 2022-03-01 11:09:49 +08:00
Sebastian Thiel
9199453548
A fix for the previous simplified reproduction 2022-03-01 11:04:41 +08:00
Sebastian Thiel
441b031a6d
further simplify the reproduction code
This is a hacky way of making changes while leaving everything else,
despite it being deactivated for now, in the hopes to not forget
to put additional difficulties back in once this particular issue
is fixed.
2022-03-01 10:20:31 +08:00
Sebastian Thiel
8c8f606e3e
reproduce issue; this time with build dependencies
They differ as these will be built for the host, so
`FeaturesFor` will not set a target specifically.
2022-03-01 09:39:39 +08:00
Sebastian Thiel
1190f5fea2
Look at FeaturesFor:: to decide if a dependency participates in feature resolution
Fixes #10431.
2022-02-28 11:30:19 +08:00
Sebastian Thiel
ac6427f755
reproduce #10431 2022-02-28 11:17:09 +08:00
Sebastian Thiel
7248f4b70d
add support for artifact dependencies (#9096)
Tracking issue: https://github.com/rust-lang/cargo/issues/9096
Original PR: https://github.com/rust-lang/cargo/pull/9992

Add 'bindeps' -Z flag for later use

A test to validate artifact dependencies aren't currently parsed.

Parse 'artifact' and 'lib' fields.

Note that this isn't behind a feature toggle so 'unused' messages will
disappear.

Transfer artifact dependencies from toml- into manifest-dependencies

There are a few premises governing the operation.

- if unstable features are not set, warn when 'artifact' or 'lib' is
  encountered.
- bail if 'lib' is encountered alone, but warn that this WOULD happen
  with nightly.
- artifact parsing checks for all invariants, but some aren't tested.

Assure serialization of 'artifact' and 'lib' fields produces suitable values during publishing

This should be the only place were these fields matter and where a cargo
manifest is actually produced. These are only for internal use, no user
is typically going to see or edit them.

Place all artifact dependency tests inta their own module

This facilitates deduplication later and possibly redistribution into
other modules if there is a better fit.

Represent artifacts that are rust libraries as another ArtifactKind

This is more consistent and probably simpler for later use.
No need to reflect the TOML data structure.

Add tests to assure only 'lib = true' artifact deps are documented

RFC-3028 doesn't talk about documentation, but for lib=true it's clear
what the desired behaviour should be.
If an artifact isn't a library though, then for now, it's transparent,
maybe.

Many more tests, more documentation, mild `Artifact` refactor

The latter seems to be a better fit for what being an artifact
really means within cargo, as it literally turns being a library
on or off, and thus only optionally becoming a normal library.

refactor to prepare for artifact related checks

Don't show a no-lib warning for artifact dependencies (with lib = false)

Tests for more artifact dependency invariants

These are merely a proof of concept to show that we are not in
a position to actually figure out everything about artifacts
right after resolution.

However, the error message looks more like a fatal error and less
like something that can happen with a more elaborate error message
with causes.

This might show that these kind of checks might be better done later
right before trying to use the information for create compile units.

Validate that artifact deps with lib=true still trigger no-lib warnings

This triggers the same warning as before, for now without any
customization to indicate it's an artifact dependency.

Use warnings instead of errors
------------------------------

This avoids the kind of harsh end of compilation in favor of something
that can be recovered from. Since warnings are annoying, users will
probably avoid re-declaring artifact dependencies.

Hook in artifact dependencies into build script runs

Even though we would still have to see what happens if they have a lib
as well. Is it built twice?

Also
----

- fly-by refactor: fix typo; use ? in method returning option
- Propagate artifact information into Units; put artifacts into place

  This means artifacts now have their own place in the 'artifact'
  directory and uplifts won't happen for them.

- refactor and fix cippy suggestion
- fix build after rebasing onto master

Create directories when executing the job, and not when preparing it.

also: Get CI to work on windows the easy way, for now.

Set directories for artifact dependencies in build script runtimes

Test remaining kinds of build-script runtime environment variables

Also
----
- Fix windows tests, the quick way.
- Try to fix windows assertions, and generalize them
- Fix second test for windows, hopefully

test for available library dependency in build scripts with lib = true

probably generally exclude all artifact dependencies with lib=false.

Pass renamed dep names along with unit deps to allow proper artifact env names

Test for selective bin:<name> syntax, as well as binaries with dashes

Test to assure dependency names are transformed correctly

assure advertised binaries and directories are actually present

This wouldn't be the case if dependencies are not setup correctly,
for instance.

Also
----
 - make it easier to see actual values even on failure

   This should help figure out why on CI something fails that works
   locally no matter what.
   Turns out this is a race condition, with my machine being on the good
   side of it so it doesn't show in testing. Fortunately it still can be
   reproduced and easily tested for.

 - refactor test; the race condition is still present though

 - Force CI to pass here by avoiding checks triggering race.

 - Fix windows build, maybe?

More tolerant is_file() checks to account for delay on CI

This _should_ help CI to test for the presence which is better than
not testing at all.

This appears to be needed as the output file isn't ready/present in time
for some reason.

The root cause of this issue is unknown, but it's definitely a race
as it rarely happens locally. When it happened, the file was always
present after the run.
Now we will learn if it is truly not present, ever, or if it's maybe
something very else.

Validate libs also don't see artifact dependencies as libraries with lib=false

Also
----

 - Add prelimiary test for validating build-time artifacts
 - Try to fix CI on gnu windows

   Which apparently generates paths similar to linux, but with .exe suffix.
   The current linux patterns should match that.

 - refactor

   Help sharing code across modules

allow rustc to use artifact dep environment variables, but…

…it needs some adjustments to actually setup the unit dependency graph
with artifacts as well.
Right now it will only setup dependencies for artifacts that are libs,
but not the artifacts themselves, completely ignoring them when they
are not libs.

Make artifact dependencies available in main loop

This is the commit message #2:
------------------------------

rough cut of support for artifact dependencies at build time…

…which unfortunately already shows that the binary it is supposed to
include is reproducibly not ready in time even though the path is
correct and it's present right after the run.

Could it be related to rmeta?

This is the commit message #3:
------------------------------

Fix test expectations as failure is typical than the warning we had before…

…and add some tolerance to existing test to avoid occasional failures.

This doesn't change the issue that it also doens't work at all for
libraries, which is nicely reproducable and hopefully helps to fix
this issue.

This is the commit message #4:
------------------------------

Probably the fix for the dependency issue in the scheduler

This means that bin() targets are now properly added to the job graph
to cause proper syncing, whereas previously apparently it would
still schedule binaries, but somehow consider them rmeta and thus
start their dependents too early, leading to races.

This is the commit message #5:
------------------------------

Don't accidentally include non-gnu windows tests in gnu windows.

Support cargo doc and cargo check

The major changes here are…

- always compile artifacts in build mode, as we literally want the
  build output, always, which the dependent might rely on being present.
- share code between the rather similar looking paths for rustdoc and
  rustc.

Make artifact messages appear more in line with cargo by using backticks

Also: Add first test for static lib support in build scripts

build-scripts with support for cdylib and staticlib

 - Fix windows msvc build

   No need to speculate why the staticlib has hashes in the name even
   though nothing else.

staticlib and cdylib support for libraries

test staticlib and cdylibs for rustdoc as well.

Also catch a seemingly untested special case/warning about the lack
of linkable items, which probably shouldn't be an issue for artifacts
as they are not linkable in the traditional sense.

more useful test for 'cargo check'

`cargo check` isn't used very consistently in tests, so when we use it
we should be sure to actually try to use an artifact based feature
to gain some coverage.

verify that multiple versions are allowed for artifact deps as well.

also: remove redundant test

This is the commit message #2:
------------------------------

Properly choose which dependencies take part in artifact handling

Previously it would include them very generously without considering
the compatible dependency types.

This is the commit message #3:
------------------------------

a more complex test which includes dev-dependencies

It also shows that doc-tests don't yet work as rustdoc is run outside of
the system into which we integrate right now.

It should be possible to write our environment variable configuration
in terms of this 'finished compilation' though, hopefully with
most code reused.

This is the commit message #4:
------------------------------

A first stab at storing artifact environment variables for packages…

…however, it seems like the key for this isn't necessarily correct
under all circumstances. Maybe it should be something more specific,
don't know.

This is the commit message #5:
------------------------------

Adjust key for identifying units to Metadata

This one is actually unique and feels much better.

This is the commit message #6:
------------------------------

Attempt to make use of artifact environment information…

…but fail as the metadata won't match as the doctest unit is, of course,
its separate unit. Now I wonder if its possible to find the artifact
units in question that have the metadata.

Properly use metadata to use artifact environment variables in doctests

This is the commit message #2:
------------------------------

Add test for resolver = "2" and build dependencies

Interestingly the 'host-features' flag must be set (as is seemingly
documented in the flags documentation as well), even though I am not
quite sure if this is the 100% correct solution. Should it rather
have an entry with this flag being false in its map? Probably not…
but I am not quite certain.

This is the commit message #3:
------------------------------

set most if not all tests to use resolver = "2"

This allows to keep it working with the most recent version while
allowing to quickly test with "1" as well (which thus far was working
fine).

All tests I could imagine (excluding target and profiles) are working now

Crossplatform tests now run on architecture aarm64 as well.

More stringent negative testing

Fix incorrect handling of dependency directory computation

Previously it would just 'hack' the deps-dir to become something very
different for artifacts.

This could easily be fixed by putting the logic for artifact output
directories into the right spot.

A test for cargo-tree to indicate artifacts aren't handled specifically

Assure build-scripts can't access artifacts at build time

Actual doc-tests with access to artifact env vars

All relevant parsing of `target = [..]`

Next step is to actually take it into consideration.

A failing test for adjusting the target for build script artifacts using --target

Check for unknown artifact target triple in a place that exists for a year

The first test showing that `target="target"` deps seemingly work

For now only tested for build scripts, but it won't be much different
for non-build dependencies.

build scripts accept custom targets unconditionally

Support target setting for non-build dependencies

This is the commit message #2:
------------------------------

Add doc-test cross compile related test

Even though there is no artifact code specific to doc testing, it's
worth to try testing it with different target settings to validate
it still works despite doc tests having some special caseing around
target settings.

This is the commit message #3:
------------------------------

A test to validate profiles work as expected for build-deps and non-build deps

No change is required to make this work and artifact dependencies 'just work'
based on the typical rules of their non-artifact counterarts.

This is the commit message #4:
------------------------------

Adjust `cargo metadata` to deal with artifact dependencies

This commit was squashed and there is probably more that changed.

This is the commit message #5:
------------------------------

Show bin-only artifacts in "resolve" of metadata as well.

This is the commit message #6:
------------------------------

minor refactoring during research for RFC-3176

This will soon need to return multiple extern-name/dep-name pairs.

This is the commit message #7:
------------------------------

See if opt-level 3 works on win-msvc in basic profile test for artifacts

This is the same value as is used in the other test of the same name,
which certainly runs on windows.

This is the commit message #8:
------------------------------

refactor

Assure the type for targets reflect that they cannot be the host target,
which removes a few unreachable!() expressions.

Put `root_unit_compile_kind` into `UnitFor`

Previously that wasn't done because of the unused `all_values()`
method which has now been deleted as its not being used anyomre.

This allows for the root unit compile kind to be passed as originally
intended, instead of working around the previous lack of extendability
of UnitFor due to ::all_values().

This is also the basis for better/correct feature handling once
feature resolution can be depending on the artifact target as well,
resulting in another extension to UnitFor for that matter.

Also
----

 - Fix ordering

   Previously the re-created target_mode was used due to the reordering
   in code, and who knows what kind of effects that might have
   (despite the test suite being OK with it).

   Let's put it back in place.

 - Deactivate test with filename collision on MSVC until RFC-3176 lands

Avoid clashes with binaries called 'artifact' by putting 'artifact/' into './deps/'

This commit addresses review comment https://github.com/rust-lang/cargo/pull/9992#discussion_r772939834

Don't rely on operator precedence for boolean operations

Now it should be clear that no matter what the first term is,
if the unit is an artifact, we should enqueue it.

Replace boolean and `/*artifact*/ <bool>` with `IsArtifact::(Yes/No)`

fix `doc::doc_lib_false()` test

It broke due to major breakage in the way dependencies are calculated.

Now we differentiate between deps computation for docs and for building.

Avoid testing for doctest cross-compilation message

It seems to be present on my machine, but isn't on linux and it's
probably better to leave it out entirely and focus on the portions
of consecutive output that we want to see at least.

A test to validate features are unified across libraries and those in artifact deps in the same target

Allow aarch64 MacOS to crosscompile to an easily executable alternative target

That way more tests can run locally.

Support for feature resolution per target

The implementation is taken directly from RFC-3176 and notably lacks
the 'multidep' part.

Doing this definitely has the benefit of making entirely clear
'what is what' and helps to greatly reduce the scope of RFC-3176
when it's rebuilt based on the latest RF-3028, what we are implementing
right now.

Also
----
- A test which prooves that artifact deps with different target don't have a feature namespace yet

- Add a test to validate features are namespaced by target

  Previously it didn't work because it relies on resolver = "2".

- 'cargo metadata' test to see how artifact-deps are presented

- Missed an opportunity for using the newly introduced `PackageFeaturesKey`

- Use a HashMap to store name->value relations for artifact environment variables

  This is semantically closer to what's intended.

  also: Remove a by now misleading comment

Prevent resolver crash if `target = "target"` is encountered in non-build dependencies

A warning was emitted before, now we also apply a fix.

Previously the test didn't fail as it accidentally used the old
resolver, which now has been removed.

Abort in parsing stage if nightly flag is not set and 'artifact' is used

There is no good reason to delay errors to a later stage when code
tries to use artifacts via environment variables which are not present.

Change wording of warning message into what's expected for an error message

remove unnecessary `Result` in `collect()` call

Improve logic to warn if dependencie are ignored due to missing libraries

The improvement here is to trigger correctly if any dependency of a
crate is potentially a library, without having an actual library target
as part of the package specification.

Due to artifact dependencies it's also possible to have a dependency
to the same crate of the same version, hence the package name
isn't necessarily a unique name anymore. Now the name of the actual
dependency in the toml file is used to alleviate this.

Various small changes for readability and consistency

A failing test to validate artifacts work in published crates as well

Originally this should have been a test to see target acquisition works
but this more pressing issue surfaced instead.

Make artifacts known to the registry data (backwards compatible)

Now artifacts are serialized into the registry on publish (at least
if this code is actually used in the real crates-io registry) which
allows the resolve stage to contain artifact information.

This seems to be in line with the idea to provide cargo with all
information it needs to do package resolution without downloading
the actual manifest.

Pick up all artifact targets into target info once resolve data is available

Even though this works in the test at hand, it clearly shows there
is a cyclic dependency between the resolve and the target data.

In theory, one would have to repeat resolution until it settles
while avoiding cycles.

Maybe there is a better way.

Add `bindeps`/artifact dependencies to `unstsable.md` with examples

Fix tests

Various small improvements

Greatly simplify artifact environment propagation to commands

Remove all adjustments to cargo-metadata, but leave tests

The tests are to record the status quo with the current code
when artifact dependencies are present and assure the information
is not entirely non-sensical.

Revert "Make artifacts known to the registry data (backwards compatible)"

This reverts commit adc5f8ad04840af9fd06c964cfcdffb8c30769b0.

Ideally we are able to make it work without altering the registry
storage format. This could work if information from the package
set is added to the resolve information.

Enrich resolves information with additional information from downloaded manifests

Resolve information comes from the registry, and it's only as rich as
needed to know which packages take part in the build.

Artifacts, however, don't influence dependency resolution, hence it
shouldn't be part of it.

For artifact information being present nonetheless when it matters,
we port it back to the resolve graph where it will be needed later.

Collect 'forced-target' information from non-workspace members as well

This is needed as these targets aren't present in the registry and
thus can't be picked up by traversing non-workspce members.

The mechanism used to pick up artifact targets can also be used
to pick up these targets.

Remove unnecessary adjustment of doc test

refactor `State::deps()` to have filter; re-enable accidentally disabled test

The initial rebasing started out with a separted `deps_filtered()`
method to retain the original capabilities while minimizing the chance
for surprises. It turned out that the all changes combined in this PR
make heavy use of filtering capabilities to the point where
`deps(<without filter>)` was unused. This suggested that it's required
to keep it as is without a way to inline portions of it.

For the original change that triggered this rebase, see

bd45ac81ba

The fix originally made was reapplied by allowing to re-use the
required filter, but without inlining it.

Always error on invalid artifact setup, with or without enabled bindeps feature

Clarify how critical resolver code around artifact is working

Remove workaround in favor of deferring a proper implementation

See https://github.com/rust-lang/cargo/pull/9992#issuecomment-1033394197
for reference and the TODO in the ignored test for more information.

truncate comments at 80-90c; cleanup

- remove unused method
- remove '-Z unstable-options'
- improve error message
- improve the way MSVC special cases are targetted in tests
- improve how executables are found on non MSVC

Avoid depending on output of rustc

There is cyclic dependency between rustc and cargo which makes it
impossible to adjust cargo's expectations on rustc without leaving
broken commits in rustc and cargo.

Add missing documentation

fix incorrect removal of non-artifact libs

This is also the first step towards cleaning up the filtering logic
which is still making some logic harder to understand than needs be.

The goal is to get it to be closer to what's currently on master.

Another test was added to have more safety regarding the overall
library inclusion logic.

inline `build_artifact_requirements_to_units()`

Simplify filtering

This adds a default filter to `state.deps(…)` making it similar to
what's currently in master, while creating another version of it
to allow setting a custom filter. This is needed as the default filter
won't allow build dependencies, which we need in this particular case.

`calc_artifact_deps(…)` now hard-codes the default filter which is
needed due to the use of `any` here:
c0e6abe384/src/cargo/core/compiler/unit_dependencies.rs (L1119)
.

Simplify filtering.
2022-02-22 08:08:42 +08:00