summaryrefslogtreecommitdiff
path: root/testsuite
Commit message (Collapse)AuthorAgeFilesLines
* Narrow scope of special-case for unqualified printing of names in core librariesBen Gamari2015-12-1582-1008/+1238
| | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 547c597112954353cef7157cb0a389bc4f6303eb modifies the pretty-printer to render names from a set of core packages (`base`, `ghc-prim`, `template-haskell`) as unqualified. The idea here was that many of these names typically are not in scope but are well-known by the user and therefore qualification merely introduces noise. This, however, is a very large hammer and potentially breaks any consumer who relies on parsing GHC output (hence #11208). This commit partially reverts this change, now only printing `Constraint` (which appears quite often in errors) as unqualified. Fixes #11208. Updates tests in `array` submodule. Test Plan: validate Reviewers: hvr, thomie, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1619 GHC Trac Issues: #11208
* Allow recursive (undecidable) superclassesSimon Peyton Jones2015-12-1544-362/+310
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch fulfils the request in Trac #11067, #10318, and #10592, by lifting the conservative restrictions on superclass constraints. These restrictions are there (and have been since Haskell was born) to ensure that the transitive superclasses of a class constraint is a finite set. However (a) this restriction is conservative, and can be annoying when there really is no recursion, and (b) sometimes genuinely recursive superclasses are useful (see the tickets). Dimitrios and I worked out that there is actually a relatively simple way to do the job. It’s described in some detail in Note [The superclass story] in TcCanonical Note [Expanding superclasses] in TcType In brief, the idea is to expand superclasses only finitely, but to iterate (using a loop that already existed) if there are more superclasses to explore. Other small things - I improved grouping of error messages a bit in TcErrors - I re-centred the haddock.compiler test, which was at 9.8% above the norm, and which this patch pushed slightly over
* Update expected test output for 32 bit platformsErik de Castro Lopo2015-12-1510-140/+146
| | | | | | | | | | | | Test Plan: Run tests on a 32 bit platform Reviewers: austin, hvr, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1627
* DynFlags Remove -fwarn-context-quantification flagBen Gamari2015-12-152-19/+18
| | | | | | | | | | | | | | | | | As mentioned in #4426 these warnings are now errors since the Great Wildcards Refactor of 2015 (1e041b7382b6aa329e4ad9625439f811e0f27232). I've opened #11221 to ensure we remove the last traces of the option in 8.2. Test Plan: validate Reviewers: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1615 GHC Trac Issues: #4426
* Test #9632 in dependent/should_compile/T9632Richard Eisenberg2015-12-142-0/+12
|
* Add testcase for #11216Ben Gamari2015-12-142-0/+7
|
* Make binds in do-blocks strict when -XStrict (#11193)Adam Sandberg Eriksson2015-12-143-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | Previously bindings in `do` blocks were omitted. With `-XStrict` ```lang=hs do content <- action other_things ``` should be equivalent to ```lang=hs do !content <- action other_things ``` Fixes #11193. Reviewers: bgamari, austin Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1612 GHC Trac Issues: #11193
* Suggest import Data.Kinds when * is out of scopeRichard Eisenberg2015-12-143-0/+17
| | | | | | | | | | | | | | | | | | | With -XTypeInType, `*` must be imported to be used. This patch makes sure the user knows this. But I'm not sure this is the best way to deal with `*`. Feedback welcome on either this small fix or the approach to `*`, in general. You may wish to see `Note [HsAppsTy]` in HsTypes if you want to take a broader view. Test Plan: dependent/should_fail/RenamingStar Reviewers: simonpj, bgamari, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1610
* Use Cxt for deriving clauses in TH (#10819)Ben Gamari2015-12-145-4/+38
| | | | | | | | | | | | | | | | | | | | | | | Summary: Deriving clauses in the TH representations of data, newtype, data instance, and newtype instance declarations previously were just [Name], which didn't allow for more complex derived classes, eg. multi-parameter typeclasses. This switches out [Name] for Cxt, representing the derived classes as types instead of names. Test Plan: validate Reviewers: goldfire, spinda, austin Reviewed By: goldfire, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1202 GHC Trac Issues: #10819
* Some more typos in commentsGabor Greif2015-12-141-1/+1
|
* Refactor type families in Template HaskellJohn Leo2015-12-1210-33/+38
| | | | | | | | | | | | | | | | Fixes #10902. Test Plan: validate Reviewers: goldfire, austin, hvr, jstolarek, bgamari Reviewed By: jstolarek, bgamari Subscribers: hvr, thomie Differential Revision: https://phabricator.haskell.org/D1570 GHC Trac Issues: #10902
* Make -XStrict imply -XStrictDataAdam Sandberg Eriksson2015-12-123-2/+14
| | | | | | | | | | | | | | Fixes #11182. Reviewers: bgamari, simonpj, austin Reviewed By: simonpj, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1592 GHC Trac Issues: #11182
* Rework the Implicit CallStack solver to handle local lets.Eric Seidel2015-12-1223-336/+337
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We can't just solve CallStack constraints indiscriminately when they occur in the RHS of a let-binder. The top-level given CallStack (if any) will not be in scope, so I've re-worked the CallStack solver as follows: 1. CallStacks are treated like regular IPs unless one of the following two rules apply. 2. In a function call, we push the call-site onto a NEW wanted CallStack, which GHC will solve as a regular IP (either directly from a given, or by quantifying over it in a local let). 3. If, after the constraint solver is done, any wanted CallStacks remain, we default them to the empty CallStack. This rule exists mainly to clean up after rule 2 in a top-level binder with no given CallStack. In rule (2) we have to be careful to emit the new wanted with an IPOccOrigin instead of an OccurrenceOf origin, so rule (2) doesn't fire again. This is a bit shady but I've updated the Note to explain the trick. Test Plan: validate Reviewers: simonpj, austin, bgamari, hvr Reviewed By: simonpj, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1422 GHC Trac Issues: #10845
* Implement -fwarn-missing-pat-syn-sigsMatthew Pickering2015-12-124-2/+38
| | | | | | | | | | | | | | | | | | | | | | | This adds a warning when a pattern synonym is not accompanied by a signature in the style of `-fwarn-missing-sigs`. It is turned on by -Wall. If the user specifies, `-fwarn-missing-exported-signatures` with `-fwarn-missing-pat-syn-sigs` then it will only warn when the pattern synonym is exported. Test Plan: ./validate Reviewers: hvr, austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1596 GHC Trac Issues: #11053
* Frontend plugins.Edward Z. Yang2015-12-126-0/+68
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Frontend plugins enable users to write plugins to replace GHC major modes. E.g. instead of saying ghc --make A B C a user can now say ghc --frontend GHC.Frontend.Shake A B C which might provide an alternative implementation of a multi-module build. For more details, see the manual entry. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: simonmar, bgamari, austin, simonpj Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1598 GHC Trac Issues: #11194
* Test #9017 in polykinds/T9017Richard Eisenberg2015-12-113-0/+35
|
* Test case for #7961.Richard Eisenberg2015-12-112-0/+27
| | | | Test case: dependent/shoud_compile/TypeLevelVec
* Add kind equalities to GHC.Richard Eisenberg2015-12-11319-1683/+2405
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This implements the ideas originally put forward in "System FC with Explicit Kind Equality" (ICFP'13). There are several noteworthy changes with this patch: * We now have casts in types. These change the kind of a type. See new constructor `CastTy`. * All types and all constructors can be promoted. This includes GADT constructors. GADT pattern matches take place in type family equations. In Core, types can now be applied to coercions via the `CoercionTy` constructor. * Coercions can now be heterogeneous, relating types of different kinds. A coercion proving `t1 :: k1 ~ t2 :: k2` proves both that `t1` and `t2` are the same and also that `k1` and `k2` are the same. * The `Coercion` type has been significantly enhanced. The documentation in `docs/core-spec/core-spec.pdf` reflects the new reality. * The type of `*` is now `*`. No more `BOX`. * Users can write explicit kind variables in their code, anywhere they can write type variables. For backward compatibility, automatic inference of kind-variable binding is still permitted. * The new extension `TypeInType` turns on the new user-facing features. * Type families and synonyms are now promoted to kinds. This causes trouble with parsing `*`, leading to the somewhat awkward new `HsAppsTy` constructor for `HsType`. This is dispatched with in the renamer, where the kind `*` can be told apart from a type-level multiplication operator. Without `-XTypeInType` the old behavior persists. With `-XTypeInType`, you need to import `Data.Kind` to get `*`, also known as `Type`. * The kind-checking algorithms in TcHsType have been significantly rewritten to allow for enhanced kinds. * The new features are still quite experimental and may be in flux. * TODO: Several open tickets: #11195, #11196, #11197, #11198, #11203. * TODO: Update user manual. Tickets addressed: #9017, #9173, #7961, #10524, #8566, #11142. Updates Haddock submodule.
* Fix infix record field fixity (#11167 and #11173).Adam Gundry2015-12-1114-7/+117
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This extends D1585 with proper support for infix duplicate record fields. In particular, it is now possible to declare record fields as infix in a module for which `DuplicateRecordFields` is enabled, fixity is looked up correctly and a readable (although unpleasant) error message is generated if multiple fields with different fixities are in scope. As a bonus, `DEPRECATED` and `WARNING` pragmas now work for duplicate record fields. The pragma applies to all fields with the given label. In addition, a couple of minor `DuplicateRecordFields` bugs, which were pinpointed by the `T11167_ambig` test case, are fixed by this patch: - Ambiguous infix fields can now be disambiguated by putting a type signature on the first argument - Polymorphic type constructor signatures (such as `ContT () IO a` in `T11167_ambig`) now work for disambiguation Parts of this patch are from D1585 authored by @KaneTW. Test Plan: New tests added. Reviewers: KaneTW, bgamari, austin Reviewed By: bgamari Subscribers: thomie, hvr Differential Revision: https://phabricator.haskell.org/D1600 GHC Trac Issues: #11167, #11173
* testsuite: Only run recomp015 on ELF-based platformsBen Gamari2015-12-111-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It fails on OS X with hundreds of messages of the form, ``` ManySections.s:196576:10: error: error: mach-o section specifier uses an unknown section type .section s65525,"",@progbits ^ ManySections.s:196579:10: error: error: mach-o section specifier uses an unknown section type .section s65526,"",@progbits ``` It fails on Windows with messages of the form, ``` ManySections.s:196579:10: error: Error: junk at the end of line, first unrecognized character is ',' ``` Test Plan: Validate Reviewers: hsyl20, thomie, austin Reviewed By: thomie, austin Differential Revision: https://phabricator.haskell.org/D1601 GHC Trac Issues: #11022
* Removed colon append operation (fixes #10785)Ben Gamari2015-12-115-14/+14
| | | | | | | | | | | | Reviewers: jgertm, austin, thomie Reviewed By: thomie Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1164 GHC Trac Issues: #10785
* T4801: Update expected allocations on DarwinBen Gamari2015-12-111-2/+3
|
* Mark retc001 as broken on DarwinBen Gamari2015-12-111-1/+2
| | | | | Due to #11204. A relatively easy fix would be to add a one second delay as described in the ticket, but this seems terrible.
* T7478: Don't expect broken on DarwinBen Gamari2015-12-111-1/+0
| | | | | This appears to be fixed as noted by goldfire on #7478 and my own experience.
* Test Trac #11187Simon Peyton Jones2015-12-102-0/+19
|
* Test Trac #11192Simon Peyton Jones2015-12-103-0/+60
|
* More typos in comments/docsGabor Greif2015-12-093-5/+5
|
* Fix DeriveAnyClass (Trac #9968)Simon Peyton Jones2015-12-095-0/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The main issue concerned things like data T a = MkT a deriving( C Int ) which is supposed to generate instance C Int (T a) where {} But the 'Int' argument (called cls_tys in the code) wasn't even being passed to inferConstraints and mk_data_eqn, so it really had no chance. DeriveAnyClass came along after this code was written! Anyway I did quite a bit of tidying up in inferConstraints. Also I discovered that this case was not covered at all data T a b = MkT a b deriving( Bifunctor ) What constraints should we generate for the instance context? We can deal with classes whose last arg has kind *, like Eq, Ord; or (* -> *), like Functor, Traversable. But we really don't have a story for classes whose last arg has kind (* -> * -> *). So I augmented checkSideConditions to check for that and give a sensible error message. ToDo: update the user manual.
* An assortment of typosGabor Greif2015-12-081-1/+1
|
* Move checking for missing signatures to RnNames.reportUnusedNamesEric Seidel2015-12-072-0/+11
| | | | | | | | | | | | | | | | | | Checking for missing signatures before renaming the export list is prone to errors, so we now perform the check in `reportUnusedNames` at which point everything has been renamed. Test Plan: validate, new test case is T10908 Reviewers: goldfire, simonpj, austin, bgamari Subscribers: thomie Projects: #ghc Differential Revision: https://phabricator.haskell.org/D1561 GHC Trac Issues: #10908
* Refactor ConDeclAlan Zimmerman2015-12-075-6/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The ConDecl type in HsDecls is an uneasy compromise. For the most part, HsSyn directly reflects the syntax written by the programmer; and that gives just the right "pegs" on which to hang Alan's API annotations. But ConDecl doesn't properly reflect the syntax of Haskell-98 and GADT-style data type declarations. To be concrete, here's a draft new data type ```lang=hs data ConDecl name | ConDeclGADT { con_names :: [Located name] , con_type :: LHsSigType name -- The type after the ‘::’ , con_doc :: Maybe LHsDocString } | ConDeclH98 { con_name :: Located name , con_qvars :: Maybe (LHsQTyVars name) -- User-written forall (if any), and its implicit -- kind variables -- Non-Nothing needs -XExistentialQuantification , con_cxt :: Maybe (LHsContext name) -- ^ User-written context (if any) , con_details :: HsConDeclDetails name -- ^ Arguments , con_doc :: Maybe LHsDocString -- ^ A possible Haddock comment. } deriving (Typeable) ``` Note that For GADTs, just keep a type. That's what the user writes. NB:HsType can represent records on the LHS of an arrow: { x:Int,y:Bool} -> T con_qvars and con_cxt are both Maybe because they are both optional (the forall and the context of an existential data type For ConDeclGADT the type variables of the data type do not scope over the con_type; whereas for ConDeclH98 they do scope over con_cxt and con_details. Updates haddock submodule. Test Plan: ./validate Reviewers: simonpj, erikd, hvr, goldfire, austin, bgamari Subscribers: erikd, goldfire, thomie, mpickering Differential Revision: https://phabricator.haskell.org/D1558 GHC Trac Issues: #11028
* Use TypeLits in the meta-data encoding of GHC.GenericsRyanGlScott2015-12-077-1049/+851
| | | | | | | | | | | | | | Test Plan: Validate. Reviewers: simonpj, goldfire, hvr, dreixel, kosmikus, austin, bgamari Reviewed By: kosmikus, austin, bgamari Subscribers: RyanGlScott, Fuuzetsu, bgamari, thomie, carter, dreixel Differential Revision: https://phabricator.haskell.org/D493 GHC Trac Issues: #9766
* Add isImport, isDecl, and isStmt functions to GHC APIRoman Shatsov2015-12-075-1/+155
| | | | | | | | | | | | Reviewers: austin, thomie, bgamari Reviewed By: thomie, bgamari Subscribers: mpickering, thomie Differential Revision: https://phabricator.haskell.org/D1518 GHC Trac Issues: #9015
* Re-export data family when exporting a data instance without an export listDavid Kraeutmann2015-12-076-10/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Whenever a data instance is exported, the corresponding data family is exported, too. This allows one to write ``` -- Foo.hs module Foo where data family T a -- Bar.hs module Bar where import Foo data instance T Int = MkT -- Baz.hs module Baz where import Bar (T(MkT)) ``` In previous versions of GHC, this required a workaround explicit export list in `Bar`. Reviewers: bgamari, goldfire, austin Reviewed By: bgamari, goldfire Subscribers: goldfire, thomie Differential Revision: https://phabricator.haskell.org/D1573 GHC Trac Issues: #11164
* Implement new `-fwarn-noncanonical-monoid-instances`Herbert Valerio Riedel2015-12-065-3/+61
| | | | | | | | | | | | | | | | This is similiar to the `-fwarn-noncanonical-monad-instances` warning implemented via #11128, but applies to `Semigroup`/`Monoid` instead and the `(<>)`/`mappend` methods (of which `mappend` is planned to move out of `Monoid` at some point in the future being redundant and thus error-prone). This warning is contained in `-Wcompat` but not in `-Wall`. This addresses #11150 Reviewed By: quchen Differential Revision: https://phabricator.haskell.org/D1553
* Update peak_megabytes_allocated for T9675Ben Gamari2015-12-041-1/+2
| | | | | | | Interestingly enough this decreased with the new pattern checker. I'm not entirely sure why at the moment as the test is merely a large record with a bunch of selectors. I wouldn't have thought this would tax the pattern checker particularly much but oh well.
* testsuite: Rename pmcheck/T7669 to pmcheck/T7669aBen Gamari2015-12-043-1/+1
| | | | This was a duplicate.
* T5642: Fix skip usageBen Gamari2015-12-041-1/+1
|
* Tidy user type errors in checkValidTypeSimon Peyton Jones2015-12-041-1/+1
| | | | | | | | | | | | | | | | | | Trac #11144 showed that we need to tidy the type in the error message generated in TcValidity.checkUserTypeError. This is still unsatisfactory. checkValidType was originally supposed to be called only on types gotten directly from user-written HsTypes. So its error messages do no tidying. But TcBinds calls it checkValidType on an /inferred/ type, which may need tidying. Still this at least fixes the bad error message in CustomTypeErrors02, which was the original ticket. Some other small refactorings: * Remove unused Kind result of getUserTypeErrorMsg * Rename isUserErrorTy --> userTypeError_maybe
* Fix egregious error in eta-reduction of data familiesSimon Peyton Jones2015-12-043-1/+22
| | | | | | | | | | | | This terrible and long-standing bug was shown up by Trac #11148. We are trying to eta-reduce a data family instance, so that we can then derive Functor or Generic. But we were assuming, for absolutely not reason whatsoever, that the type variables were lined up in a convenient order. The fact that it ever worked was a fluke. This patch fixes it properly. Main change is in eta_reduce in TcInstDcls.tcDataFamInstDecl
* Add derived constraints for wildcard signaturesSimon Peyton Jones2015-12-043-0/+21
| | | | | | This fixes Trac #11016 See Note [Add deriveds for signature contexts] in TcSimplify]
* Case-of-empty-alts is trivial (Trac #11155)Simon Peyton Jones2015-12-043-1/+21
| | | | | | | | | | As you'll see from Trac #11155, the code generator was confused by a binding let x = y in .... Why did that happen? Because of a (case y of {}) expression on the RHS. The right thing is just to expand what a "trivial" expression is. See Note [Empty case is trivial] in CoreUtils.
* Make callToPats deterministic in SpecConstrBartosz Nitka2015-12-047-23/+82
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes a non-determinism bug where where depending on the order of uniques allocated, the specialized workers would have different order of arguments. Compare: ``` $s$wgo_s1CN :: Int# -> Int -> Int# [LclId, Arity=2, Str=DmdType <L,U><L,U>] $s$wgo_s1CN = \ (sc_s1CI :: Int#) (sc_s1CJ :: Int) -> case tagToEnum# @ Bool (<=# sc_s1CI 0#) of _ [Occ=Dead] { False -> $wgo_s1BU (Just @ Int (I# (-# sc_s1CI 1#))) (Just @ Int sc_s1CJ); True -> 0# } ``` vs ``` $s$wgo_s18mTj :: Int -> Int# -> Int# [LclId, Arity=2, Str=DmdType <L,U><L,U>] $s$wgo_s18mTj = \ (sc_s18mTn :: Int) (sc_s18mTo :: Int#) -> case tagToEnum# @ Bool (<=# sc_s18mTo 0#) of _ [Occ=Dead] { False -> $wgo_s18mUc (Just @ Int (I# (-# sc_s18mTo 1#))) (Just @ Int sc_s18mTn); True -> 0# } ``` Test Plan: I've added a new testcase ./validate Reviewers: simonmar, simonpj, austin, goldfire, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1508 GHC Trac Issues: #4012
* T5642: Skip it entirelyBen Gamari2015-12-041-1/+1
| | | | | It uses so much memory that it would be unsafe to even allow it to run as it may jeopardize the stability of the build-bots.
* T5642 is brokenBen Gamari2015-12-041-0/+1
| | | | This appears to be due to the new exhaustiveness checker. See #11163.
* Bump allocations for T783Ben Gamari2015-12-041-1/+3
| | | | | The new pattern match checker increased allocations by over 100%. Tracking in #11162.
* Update test outputBen Gamari2015-12-031-0/+4
|
* Revert "Create empty dump files when there was nothing to dump"Ben Gamari2015-12-034-62/+0
| | | | | This reverts commit 8cba907ad404ba4005558b5a8966390159938172 which broke `-ddump-to-file`.
* testsuite: haddock.compiler: Bump expected allocationsBen Gamari2015-12-031-1/+2
|
* Major Overhaul of Pattern Match Checking (Fixes #595)George Karachalias2015-12-0364-53/+579
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adresses several problems concerned with exhaustiveness and redundancy checking of pattern matching. The list of improvements includes: * Making the check type-aware (handles GADTs, Type Families, DataKinds, etc.). This fixes #4139, #3927, #8970 and other related tickets. * Making the check laziness-aware. Cases that are overlapped but affect evaluation are issued now with "Patterns have inaccessible right hand side". Additionally, "Patterns are overlapped" is now replaced by "Patterns are redundant". * Improved messages for literals. This addresses tickets #5724, #2204, etc. * Improved reasoning concerning cases where simple and overloaded patterns are matched (See #322). * Substantially improved reasoning for pattern guards. Addresses #3078. * OverloadedLists extension does not break exhaustiveness checking anymore (addresses #9951). Note that in general this cannot be handled but if we know that an argument has type '[a]', we treat it as a list since, the instance of 'IsList' gives the identity for both 'fromList' and 'toList'. If the type is not clear or is not the list type, then the check cannot do much still. I am a bit concerned about OverlappingInstances though, since one may override the '[a]' instance with e.g. an '[Int]' instance that is not the identity. * Improved reasoning for nested pattern matching (partial solution). Now we propagate type and (some) term constraints deeper when checking, so we can detect more inconsistencies. For example, this is needed for #4139. I am still not satisfied with several things but I would like to address at least the following before the next release: Term constraints are too many and not printed for non-exhaustive matches (with the exception of literals). This sometimes results in two identical (in appearance) uncovered warnings. Unless we actually show their difference, I would like to have a single warning.
View Lorry Controller Status