Struggling to find things in the new stdlib for 5.0... e.g. where is addingReportingOverflow implemented?

carlos4242 · December 6, 2018, 7:54am

I'm having trouble upgrading my stdlib interpretation. It seems like (as you would expect) quite a few things have changed since swift 4.2. I'm trying to keep my version up to speed but struggling a bit. For example, I can't figure out where the function body for addingReportingOverflow is for integers? I can see the definition in the FixedWidthInteger protocol and see it mentioned in the comments in the gyb file but can't find the body! Can anyone give pointers please?

orobio · December 6, 2018, 9:08am

It's a bit difficult to find due to that the function name is generated by gyb. This should be it:

github.com

apple/swift/blob/d7139bb85a52e0c02b343ecd9256fe4aa5190f8e/stdlib/public/core/IntegerTypes.swift.gyb#L1259


      
          %   end
              Builtin.condfail(overflow)
              lhs = ${Self}(result)
            }
          %       end
          
          
%       for x in chain(*binaryArithmetic.values()):
          
          
${overflowOperationComment(x.operator)}
            @_transparent
            public func ${x.name}ReportingOverflow(
              ${x.firstArg} other: ${Self}
            ) -> (partialValue: ${Self}, overflow: Bool) {
          %         if x.kind == '/':
              // No LLVM primitives for checking overflow of division operations, so we
              // check manually.
              if _slowPath(other == (0 as ${Self})) {
                return (partialValue: self, overflow: true)
              }
          %           if signed:
              if _slowPath(self == ${Self}.min && other == (-1 as ${Self})) {

carlos42421 · December 6, 2018, 11:14am

Yes, that looks like it! Thank you!!

Is there any high level overview of the changes that have been made to stdlib in Swift 5.0? Or at least some discussion of the various significant design changes/structure that have been made in key areas? (i.e. Int, Pointer, Enum, etc.)

orobio · December 7, 2018, 8:02am

Not that I know of (but that doesn't say much).

benrimmington · December 7, 2018, 4:12pm

implemented proposals
deprecated or obsoleted APIs
ABI stability changes
source compatibility changes
CHANGELOG.md (not comprehensive)
Xcode Release Notes (in early 2019)
- e.g. Swift 4.2 Release Notes for Xcode 10

Ben_Cohen · December 8, 2018, 1:39am

This is a great list!

Just a word of warning about this one:

This is just a list of changes since we last re-baselined, which was done fairly frequently at the early stages of the checking tool because compiler changes can generate lots of churn. It isn't a full delta between 4.2 and 5.0.

Ben_Cohen · December 8, 2018, 1:44am

I've been thinking that given how little gyb there is left at this point, it's time to go all in and degyb the remaining files. IntegerTypes changes so rarely that it's not a huge win to keep it gybbed. Alternatively we could do what is done elsewhere, which is keep the gybbed files, and have them be the thing you modify, but also check in the gyblets too, perhaps with a test that confirms the generated files match the gyb. This would probably help with attempts to make the std lib nicer to work on with Xcode or an LSP-enhanced editor.

This would make for a great starter bug for anyone interested.

edit: to clarify, I'm talking about degybbing the std lib code, not the tests quite yet – degybbing those would be a much bigger project and possibly should wait on more language features.

Alejandro · December 8, 2018, 2:06am

For more clarification for someone that decides to pick this up, how would you suggest degybbing IntegerTypes? Do you suggest splitting them into files like Int.swift, UInt.swift, etc.? Or shoving them all into a single file? (My personal preference would be to split into separate files.)

carlos4242 · December 8, 2018, 11:17am

I am very new to all of this but kinda love this idea. Aside from the obvious problems of code duplication. I'm actually doing exactly this in my micro stdlib. Currently still put everything in one file but separate files seems sense? But wondering what the core team think? It's still quite a big change isn't it?

Alejandro · December 8, 2018, 5:55pm

Gyb begone:
Original PR: [stdlib] De-gyb everything by Azoy · Pull Request #21143 · apple/swift · GitHub
Part 1: [stdlib][Part 1] De-gyb almost everything by Azoy · Pull Request #21149 · apple/swift · GitHub

dennisvennink · December 8, 2018, 7:19pm

I don't think we should prematurely delete all .gyb files from the Standard Library.

Don't get me wrong, I don't like them either. They're cumbersome to work with and don't integrate into editor-based workflows.

But I think we should keep them for now. Working with them is uncommon and manually editing repetitive code has the potential for overlooked errors to creep in.

Alejandro · December 8, 2018, 7:27pm

But isn't this the reason why we have tests?

dennisvennink · December 8, 2018, 10:10pm

Sure, but then we're moving some of the complexity from gyb to tests. With gyb we can at least reason that if the tests pass for one generated arity or type there's a high likelyhood that they will also pass for other arities or types.

I'm not against the idea. But if we do go ahead with the deletion we need to put a system in place that ensures we're not hitting regressions or bugs.

My preference would be the following:

Keep the .gyb files around.
Generate the output manually.

Note: it might be wise to add a comment at the top of all .gyb files that specifies its relative location with a disclaimer that the user is not supposed to edit the generated .swift file.
Change the .swift.gyb extensions to .swift in CMakeLists.txt.
Add tests that validate the output per @Ben_Cohen's suggestion.

Note: for this to work we need to use gyb --line-directive "" in step 2.