Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[stable] Fix #2973 #2974

Open
wants to merge 4 commits into
base: stable
Choose a base branch
from
Open

[stable] Fix #2973 #2974

wants to merge 4 commits into from

Conversation

kinke
Copy link
Contributor

@kinke kinke commented Oct 29, 2024

No description provided.

@kinke kinke changed the base branch from master to stable October 29, 2024 16:11
Copy link

github-actions bot commented Oct 29, 2024

✅ PR OK, no changes in deprecations or warnings

Total deprecations: 8

Total warnings: 0

Build statistics:

 statistics (-before, +after)
-executable size=5293368 bin/dub
-rough build time=63s
+executable size=5297464 bin/dub
+rough build time=62s
Full build output
DUB version 1.38.0, built on Jul  4 2024
LDC - the LLVM D compiler (1.39.0):
  based on DMD v2.109.1 and LLVM 18.1.6
  built with LDC - the LLVM D compiler (1.39.0)
  Default target: x86_64-unknown-linux-gnu
  Host CPU: znver3
  http://dlang.org - http://wiki.dlang.org/LDC


  Registered Targets:
    aarch64     - AArch64 (little endian)
    aarch64_32  - AArch64 (little endian ILP32)
    aarch64_be  - AArch64 (big endian)
    amdgcn      - AMD GCN GPUs
    arm         - ARM
    arm64       - ARM64 (little endian)
    arm64_32    - ARM64 (little endian ILP32)
    armeb       - ARM (big endian)
    avr         - Atmel AVR Microcontroller
    bpf         - BPF (host endian)
    bpfeb       - BPF (big endian)
    bpfel       - BPF (little endian)
    hexagon     - Hexagon
    lanai       - Lanai
    loongarch32 - 32-bit LoongArch
    loongarch64 - 64-bit LoongArch
    mips        - MIPS (32-bit big endian)
    mips64      - MIPS (64-bit big endian)
    mips64el    - MIPS (64-bit little endian)
    mipsel      - MIPS (32-bit little endian)
    msp430      - MSP430 [experimental]
    nvptx       - NVIDIA PTX 32-bit
    nvptx64     - NVIDIA PTX 64-bit
    ppc32       - PowerPC 32
    ppc32le     - PowerPC 32 LE
    ppc64       - PowerPC 64
    ppc64le     - PowerPC 64 LE
    r600        - AMD GPUs HD2XXX-HD6XXX
    riscv32     - 32-bit RISC-V
    riscv64     - 64-bit RISC-V
    sparc       - Sparc
    sparcel     - Sparc LE
    sparcv9     - Sparc V9
    spirv       - SPIR-V Logical
    spirv32     - SPIR-V 32-bit
    spirv64     - SPIR-V 64-bit
    systemz     - SystemZ
    thumb       - Thumb
    thumbeb     - Thumb (big endian)
    ve          - VE
    wasm32      - WebAssembly 32-bit
    wasm64      - WebAssembly 64-bit
    x86         - 32-bit X86: Pentium-Pro and above
    x86-64      - 64-bit X86: EM64T and AMD64
    xcore       - XCore
   Upgrading project in /home/runner/work/dub/dub/
    Starting Performing "release" build using /opt/hostedtoolcache/dc/ldc2-1.39.0/x64/ldc2-1.39.0-linux-x86_64/bin/ldc2 for x86_64.
    Building dub 1.39.0-beta.1+commit.6.g76f675d0: building configuration [application]
source/dub/internal/dyaml/composer.d(210,43): Deprecation: cannot access overlapped field `Event.implicit` with unsafe bit patterns in `@safe` code
source/dub/internal/dyaml/composer.d(232,43): Deprecation: cannot access overlapped field `Event.implicit` with unsafe bit patterns in `@safe` code
source/dub/internal/dyaml/composer.d(336,43): Deprecation: cannot access overlapped field `Event.implicit` with unsafe bit patterns in `@safe` code
source/dub/internal/dyaml/event.d(196,5): Deprecation: cannot access overlapped field `Event.explicitDocument` with unsafe bit patterns in `@safe` code
source/dub/internal/dyaml/event.d(214,5): Deprecation: cannot access overlapped field `Event.explicitDocument` with unsafe bit patterns in `@safe` code
source/dub/internal/dyaml/event.d(241,5): Deprecation: cannot access overlapped field `Event.implicit` with unsafe bit patterns in `@safe` code
source/dub/internal/dyaml/event.d(148,5): Deprecation: cannot access overlapped field `Event.implicit` with unsafe bit patterns in `@safe` code
source/dub/internal/dyaml/event.d(148,5): Deprecation: cannot access overlapped field `Event.implicit` with unsafe bit patterns in `@safe` code
     Linking dub
STAT:statistics (-before, +after)
STAT:executable size=5297464 bin/dub
STAT:rough build time=62s

@@ -563,7 +563,8 @@ class Project {
(VersionRange range) {
// See `dub.recipe.selection : SelectedDependency.fromYAML`
assert(range.isExactVersion());
return m_packageManager.getPackage(dep.name, vspec.version_);
auto tmp = m_packageManager.getPackage(basename, vspec.version_);
return resolveSubPackage(tmp, subname, true);
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This fixes the testcase in #2973. Not sure if this is the right fix though; PackageManager.getPackage() returning the parent package when given a subpackage name doesn't make a lot of sense IMO.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah it doesn't make a lot of sense but it's always been this way. It was one of the things I wanted to fix when I introduced PackageName but never got around to it.
For dependency resolution we always store references to parent package, not subpackage, because all subpackages should resolve to the same parent. I would need to inspect the code to see if that is really the right fix.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay fine if it's always been like that.

@kinke kinke changed the title Fix #2973 [stable] Fix #2973 Oct 29, 2024
@@ -98,7 +98,7 @@ version "1.0.0"`, PackageFormat.sdl);
assert(dub.project.hasAllDependencies(), "project has missing dependencies");
assert(dub.project.getDependency("b", true), "Missing 'b' dependency");
assert(dub.project.getDependency("c", true), "Missing 'c' dependency");
assert(dub.project.getDependency("c", true), "Missing 'd' dependency");
assert(dub.project.getDependency("d", true), "Missing 'd' dependency");
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just happened to notice this while browsing the tests.

@kinke kinke marked this pull request as ready for review October 31, 2024 14:37
@kinke kinke requested a review from Geod24 October 31, 2024 15:03
Copy link
Member

@Geod24 Geod24 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! By when do you need this reviewed ?

@@ -563,7 +563,8 @@ class Project {
(VersionRange range) {
// See `dub.recipe.selection : SelectedDependency.fromYAML`
assert(range.isExactVersion());
return m_packageManager.getPackage(dep.name, vspec.version_);
auto tmp = m_packageManager.getPackage(basename, vspec.version_);
return resolveSubPackage(tmp, subname, true);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah it doesn't make a lot of sense but it's always been this way. It was one of the things I wanted to fix when I introduced PackageName but never got around to it.
For dependency resolution we always store references to parent package, not subpackage, because all subpackages should resolve to the same parent. I would need to inspect the code to see if that is really the right fix.

@kinke
Copy link
Contributor Author

kinke commented Oct 31, 2024

By when do you need this reviewed ?

I assume you've already reviewed this, and if you haven't, just expand the diff context - all other branches do the subpackage resolution (after getting the base package). :) - This is IMO a major release blocker, so v1.39 final should definitely have this.

`{ "fileVersion": 1, "versions": { "b": "1.0.0" } }`);
root.writePackageFile("b", "1.0.0",
`{ "name": "b", "version": "1.0.0", "subPackages": [ { "name": "a" } ] }`);
});
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Btw thx again for the test framework, sooo much better than the old tests...

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wish we had a similar filesystem abstract in Phobos to make this kind of unittests the norm. It is so much more expressive.
I really need to finish it though, there's an issue with Windows at the moment which prevents mimicking the real world properly.

@Geod24
Copy link
Member

Geod24 commented Oct 31, 2024

I assume you've already reviewed this, and if you haven't, just expand the diff context - all other branches do the subpackage resolution (after getting the base package). :) - This is IMO a major release blocker, so v1.39 final should definitely have this.

Do you know what introduced the regression ? I am fairly sure it used to work ?

@kinke
Copy link
Contributor Author

kinke commented Oct 31, 2024

Do you know what introduced the regression ? I am fairly sure it used to work ?

Oh, I thought this was all revamped after v1.38, but no, the 'problematic' line is the same as was in v1.38.0, which works for the original test case. Hmm...

@kinke
Copy link
Contributor Author

kinke commented Oct 31, 2024

Hmm, this looks suspicious:

logDiagnostic("Lazily loading package %s:%s from %s", name.main, vers, path);
auto p = mgr.load(path);
enforce(
p.version_ == vers,
format("Package %s located in %s has a different version than its path: Got %s, expected %s",
name, path, p.version_, vers));
mgr.addPackages(this.fromPath, p);
return p;

It returns the package from the path, which is always going to be a parent package.

}

return null;
}
Copy link
Contributor Author

@kinke kinke Nov 1, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've totally reworked the fix, tackling the PackageManager API instead and resolving the subpackage in the lazy-loading getPackage() case (that was the regression AFAICT), as well as newly in loadSCMPackage().

With more context now, I see that resolveSubPackage() is actually to be avoided, as it results in a full packages scan, killing the lazy-loading advantages. It's still used if the dub.selections.json contains a path-based selection, so with these current changes, we still get a full scan whenever depending on a subpackage of a path-selected parent package.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants