This issue extends to other API as well:

var date = calendar.date(from: DateComponents(year: 2023))!
date = calendar.date(bySetting: .weekOfYear, value: 5, of: date)!
calendar.component(.weekOfYear, from: date) // expected “5”, yields “6”

Just to be clear - the "Reduce Transparency" setting must be enabled before launching the app. Changing it while the app is running doesn't appear to trigger the behaviour.

This appears to be fixed in version 17.0.0

My first guess is that https://reviews.llvm.org/D116342 was the fix.

Some great investigation from the teams working on the AWS tools:

https://github.com/aws/aws-sdk/issues/469#issuecomment-1447842544

It sounds fixed on server side by Apple.

Update:

From my tests, it appears this is resolved in macOS Ventura. But it still affects Big Sur and Monterey.

I'm not sure about the iOS side - haven't tested yet.

I think we are supposed to override managedObjectContext to implement this. When NSPersistentDocument needs the coordinator it gets it goes via this property.

Thank you for the quick answer!

Can you elaborate on why a 4k alignment in the section header can cause the linker to insert 4k fill bytes? The symbol (Character_toUpperCaseEx_5e336fa9cb982976a8ba6aaa89c54c23324f695a) after the 4k of fill bytes at address 0x100158c40 is certainly not 4k aligned. If anything, I would expect the linker to fill in less than 4k filler bytes, so that the symbol is 4k aligned. What is the linker trying to achieve here?

Also note that this occurrence of 4k filler bytes is placed in the middle of the __text section of one input object file; I would expect the section alignment to be used when multiple sections of the same kind but from different object files are concatenated.

Furthermore, why are earlier versions of ld64 produce a working binary with the same input?

As a side note, if I bump the section alignment to 16k this sequence of filler bytes before the symbol Character_toUpperCaseEx_5e336fa9cb982976a8ba6aaa89c54c23324f695a disappears, and the emitted binary works with the latest available ld64 version.

I would really love to understand the behaviour around this.

I’ve noticed that the bug doesn’t happen when I run ALL target unit tests. It only happens when I run class tests or a specific test.

Please know that our engineering team has determined that this issue behaves as intended based on the information provided.

The __text section in helloworld-unaligned-ptrs.o is 4KB aligned. So, when linked with other code, ld will attempt to align it, which means it will use fill bytes, in this case they are NOPs.

This issue when working for a corporation with a proxy is very annoying, and compiling libgit2.dlyb is no longer an option because the library is signed and XCode wont load it anymore.

As of now, it falls to Apple to fix this, and respect the proxy settings set in the OS.

Something that was not mentioned is that DSC works on M1 MBP, but doesn't work on the 2019 MBP. So this is specifically impacting the Intel stack.

Related thread on apple/swift-package-manager: https://github.com/apple/swift-package-manager/issues/4581

This is still an issue with Monterey 12.6.2.

Xcode 14.1 fixed the issues. Other issues are from third party libraries packaging.

Thanks, I modified the sample project to use NavigationStack and that appears fine. However, when I tried to use NavigationSplitView there is a table row deselection bug. I'll submit that as another feedback however I thought I would attach the project and a screen-capture so you can see it.

https://youtube.com/shorts/On_8alWwox8?feature=share

Thanks for your feedback. This looks like an issue that you need to resolve.

And, this can be resolved by using the new Navigation APIs to avoid the view identity issues described.

Please close this report if resolved, or let us know if still an issue for you.

Thank you.

I’ve attached a sample project which reproduces this bug.

The same is also available on Github: https://github.com/dezinezync/FB11739659

Thank you, Nikhil.

Associated Developer Forums Post - https://developer.apple.com/forums/thread/719444

H4sIAD1ZaGMCA1POzEvOKU1JVbApLknJzNfLsOPiKsvPTFFw00jOSCzSUijWVKjmUlAoLijKzCtJ0yjWUVBS0rTmquUCAAIitqQ6AAAA