1

Does anyone know if the following is a bug in the open source Swift project (Sourcekit) or Xcode?

In Xcode, I'm used to automatically getting a closing bracket }, ] or ) when typing something after a {, [ or (.

Like this. 
func foo() { * presses enter *

⇒

func foo() {
}

and

let arr = [ * presses enter *

⇒

let arr = [
]

and

let tuple = ( * presses enter *

⇒

let tuple = (
)

I've noticed that this functionality disappears sometimes, and I've finally managed to identify its cause:

It turns out that if my swift file happens to contain commented out code, specifically of the following form, the auto balancing of the respective bracket type will stop working.

// { bla
// }

// [ bla
// ]

// ( bla
// )

So you can try this by copy pasting the above comments into a swift source file and see that auto-balancing will stop working.

The bug will be triggered for both block comments and line comments, but the open and close brackets must be on separate lines, and the open bracket must be followed by something (eg "bla" as in the examples).

8 Likes
2

Wow, you're genius! I never could figure out what caused this and it happens all the time!
Just tested it and it's exactly like you describe.

Now if you can also figure out why most of the cool keyboard shortcuts don't work… :slight_smile: (e.g. Command+Option+G for find and select next – to be fair, not even picking from the menu works; Just a beep)

3

Sorry to revive this old thread, but I was surprised that this very noticeable and annoying bug wasn't fixed in Xcode 10.2.

I didn't report it partly because I didn't know if the bug is in SourceKit or Xcode (see OP), ie if I should file a Jira or radar, and partly because it's such a glaring bug that I thought most users must have noticed.

1 Like
4

If I were you I’d file a radar. It affects Xcode, so it’s a valid radar candidate.

5

In case it's helpful, the bug doesn't present in obj-c sources in Xcode.

6

OK, filed 49768782.

The experience of using Xcode with this long standing glaring bug and having to file a radar for it has made me so frustrated that I had to include a little rant in the radar.

And another one here.

I'm baffled by the fact that this bug wasn't fixed in Xcode 10.2. To me, this is the most irritating thing about Xcode. How can it pass even the most basic QA checks?

It makes me wonder what process/culture within Apple it is that prevents bugs like this from just being quickly noticed and fixed.

Does fixing any bug, even very noticeable ones like this, always require end users to go through the soul-crushing trouble of filing radars?

Given that 99.9% of all users are probably even less inclined than me to file radars, I would not be surprised if my radar turns out to not be a dup which, I worry, will result in it getting low priority.

Are Apple using something else than Xcode for writing Swift code?

This is similar to a car manufacturer not noticing that an updated car model looses power steering after using the breaks, or waiting for sufficiently many customer complaints before fixing it, minus the risk of personal injury etc.

2 Likes
7

It seems like this bug might have been partly fixed, because the example in the OP will no longer trigger the bug, but eg this will:

// The following block comment stops auto balancing of () [] and {} from
// working anywhere within the same file. NOTE: Specific details of the
// block comment's contents matter, for example the closing brackets
// must be the first character of a line, or the bug won't be triggered.

/*
func foo(
    a: Int,
    b: Int
) -> [Int] {
    return [
        a,
        b
]
}
*/

// NOTE ALSO that you can't simply copy paste this block-comment
// in Xcode since Xcode will unfortunately re-/un-indent its contents.
// So you have to paste it using an external editor or manually undo
// Xcode's re-/un-indentation after pasting it.
8

I'm very confused that you call this "the most irritating thing about Xcode" or a "very noticable one". Since this bug only appears if you have commented out code (which is a bad smell by the way) and people try to prevent such code, I don't think your subjective prioritization has to be shared by Apple employees. I personally have never really noticed this.

The issue you are reporting is merely a "convenience" issue which you seem to rely on heavily. But there are also many critical bugs out there which prevent features in apps from working entirely and cause crashes or simply have a different behavior than documented or expected. Such issues can cause serious financial problems for enterprises, who then struggle to pay their employees and people might lose their jobs as a result of this. Even for those Apple doesn't seem to have enough man power, so I really don't understand how you can go so far to state your problem is the most important one. If anything, then those people should get mad at Apple.

Also you're stating "that 99.9% of all users are probably even less inclined than me to file radars" but I completely disagree. Until @Diggory recommended you to actually file a radar (and not only talk about it), you were just as lazy as anybody else even though you seem to be quite pissed of this bug. Note that even if you're not sure if something is a bug within Xcode, as long as the bug happens in Xcode, you can always report it and Apple employees will make the "it's an issue with Xcode or not" decision for you. They will probably know that.

I'm sorry if this sounds too hard, but I really think next time you come across something that's "irritating" for you (but isn't a serious risk for your business), you should really just report the issue and if you want to open a thread, don't make any bold statements about the importance of your problem. If it really is such an important one, the community will react accordingly and it's importance will be proven naturally.

9

We all have something to rant about. Even you :grinning:. If I had a nickel for every rant I put into a radar...

I once filed a radar about problems due to Obj-c having a flat namespace causing me problems with a suite of Photoshop filters that all had shared Cocoa code. I started my bug report with "I know you'll never fix this, but..." The guy who read my bug report sent me back a message saying I shouldn't be so negative, they might fix it. I'm sure it's not fixed to this day.

Anyway, if your rant is longer than your bug report that's probably counter-productive. I can't say whether insulting the Apple engineers will get you positive or negative results on the bug. The main problem is the entire radar system is a black hole. One always tries to make their bug report stick out so it'l get fixed. It's all just part of life here in Apple-land.

1 Like
10

First, I wish I could be more constructive, but for me, this is the annoying little tip of a more critical iceberg, and I think that sometimes, showing your frustration can actually be constructive. Also, I would like to point out that my frustration is of course not directed towards Apple engineers (or any other person) but towards "the system/structure".

It is a convenience feature, sure, and stuff like auto balancing brackets gets into muscle memory after a while which makes it really annoying when it's sometimes there and sometimes not.

I do temporarily comment out code every now and then, yes, and I simply expect a professional IDE to be able to handle that without problems.

For example, I might comment out a piece of code while writing an improvement, or I might paste some code as a commented out temporary reference. Also, doc comments can include code examples, the standard library is full of them. (I do not, of course, leave (non-doc) commented out code in production code.)

If so, of course they should be mad at Apple and let both Apple and the community know about the problems and their frustration. They would probably ask if anyone else has the same problems and then, if necessary, spend even more of their precious time to isolate and formulate bugs.

There's no reason you can't get mad about critical bugs and irritated by long standing annoying bugs.

I have reported 103 Jiras and probably 100+ radars (found no UI to see the actual number), including some small overlap of old Swift bugs before Jira, and I'd not be surprised if that's more than what 99.9% of Swift/Xcode users has bothered to report.

I should probably adjust my tone, but the time I spend on bumping into, identifying, working around, filing and keeping track of bugs in Swift and Xcode makes it hard.

Well, this thread was my attempt. : )

11

This is one area where I think the language server and a built in formatter would really help, as it would open this type of formatting up outside of whatever mechanism Xcode uses, which is rather buggy compared to other IDEs. Allowing the community to fix these types of issues could help a lot, depending on the difficultly.

2 Likes