Commit Graph

8 Commits

Author SHA1 Message Date
Henrik G. Olsson
cbc0ec3b88 Add -verify-ignore-unrelated where necessary (NFC)
These are tests that fail in the next commit without this flag. This
does not add -verify-ignore-unrelated to all tests with -verify, only
the ones that would fail without it. This is NFC since this flag is
currently a no-op.
2025-10-04 14:19:52 -07:00
Alex Hoppen
66104395d7 [Sema/SourceKit] Emit same diagnostics for missing protocol requirements on the command line and in SourceKit
Some editors use diagnostics from SourceKit to replace build issues. This causes issues if the diagnostics from SourceKit are formatted differently than the build issues. Make sure they are rendered the same way, removing most uses of `DiagnosticsEditorMode`.

To do so, always emit the `add stubs for conformance` note (which previously was only emitted in editor mode) and remove all `; add <something>` suffixes from notes that state which requirements are missing.

rdar://129283608
2024-08-07 14:01:30 -07:00
Luciano Almeida
1184492d25 [Diagnostics] SR-11419 Diagnose protocol stub note in editor mode only (#28101)
* [TypeChecker] Enclosing stubs protocol note within editor mode

* [test] Removing note from test where there is no -diagnostics-editor-mode flag

* Formatting modified code

* [tests] Fixing tests under validation-tests
2019-11-06 07:42:48 -08:00
Xi Ge
1535bea268 FixCode: issue a separate note for protocol-stub fixit when the fixit location is in another file
Under non-editor mode, the fixit for inserting protocol stubs is associated with a note
pointing to the missing protocol member declaration which could stay in a separate file from
the conforming type, leading to the behavior of rdar://51534405. This change checks if
the fixit is in a separate file and issues another note to carry the fixit if so.

rdar://51534405
2019-07-10 12:30:54 -07:00
Karoy Lorentey
666a22feff [test] Modernize hashing throughout the test suite 2018-11-29 17:38:29 +00:00
Ben Cohen
a4230ab2ad [stdlib] Update stdlib to 4.0 and reorganize compatibility shims (#17580)
* Update stdlib to 4.0 and move all compatibility shims into a dedicated source file
2018-06-29 06:26:52 -07:00
Jordan Rose
6bd7e5e5b4 Make sure protocol witness errors don't leave the conformance context
That is, if there's a problem with a witness, and the witness comes
from a different extension from the conformance (or the original type,
when the conformance is on an extension), put the main diagnostic on
the conformance, with a note on the witness. This involves some
shuffling and rephrasing of existing diagnostics too.

There's a few reasons for this change:

- More context. It may not be obvious why a declaration in file
  A.swift needs to be marked 'public' if you can't see the conformance
  in B.swift.

- Better locations for imported declarations. If you're checking a
  conformance in a source file but the witness came from an imported
  module, it's better to put the diagnostic on the part you have
  control over. (This is especially true in Xcode, which can't display
  diagnostics on imported declarations in the source editor.)

- Plays better with batch mode. Without this change, you can have
  diagnostics being reported in file A.swift that are tied to a
  conformance declared in file B.swift. Of course the contents of
  A.swift also affect the diagnostic, but compiling A.swift on its
  own wouldn't produce the diagnostic, and so putting it there is
  problematic.

The change does in some cases make for a worse user experience,
though; if you just want to apply the changes and move on, the main
diagnostic isn't in the "right place". It's the note that has the info
and possible fix-it. It's also a slightly more complicated
implementation.
2018-05-10 19:31:12 -07:00
Max Moiseev
bfddc4a763 [stdlib] Make default implementations of bitwise operators as obsoleted
Fixes: https://bugs.swift.org/browse/SR-7019

Prior to Swift 4 and the new integers, there was a protocol called
`BitwiseOperations`. It was deemed not needed with the introduction of
the integer protocols. But, for backward compatibility, it was left in
the standard library as `_BitwiseOperations` with a conditionally
available typealias `BitwiseOperations`. That protocol declares only the
"non-muating" operators, the mutating ones (i.e. `|=` and friends) are
defined as free functions. They are implemented in terms of
`_BitwiseOperations` protocol requirements, which is reasonable.

In the new integer protocols we established a
convention to provide default implementations for non-mutating functions
in terms of mutating ones (exactly the opposite of a much earlier
decision made for `BitwiseOperations`). So now, when you define a type
that conforms to the `FixedWidthInteger`, even though both mutating and
non-mutating bitwise operations are required, the default implementation
of `|` comes from extension FixedWidthInteger, and the default
implementation of `|=` comes from the _BitwiseOperations free functions.
And they are mutually recursive. Hence the crash.

This commit breaks the recursion by marking default implementations for
`|` etc. in `_BitwiseOperations` obsoleted from Swift 4.1 onward. The
test is also added to make sure the change helps.
2018-02-20 16:31:20 -08:00