Issue565

Title Stop ignoring warnings on Windows
Priority wish Status resolved
Superseder Nosy List florian, malte, silvan
Assigned To Keywords
Optional summary
~~PR: https://github.com/aibasel/downward/pull/160/files~~

Created on 2015-07-26.17:10:38 by florian, last changed by florian.

Summary
PR: https://github.com/aibasel/downward/pull/160/files~~
Messages
msg11190 (view) Author: florian Date: 2023-07-25.16:51:40
The code is merged and issue1096 contains the follow-up work.
msg11187 (view) Author: florian Date: 2023-07-25.16:31:02
Looking over the cases, I think at least some of them should be improved but I would leave others and thus also the flag to ignore them in place. I'll open a new issue and will merge and close this one.
msg11184 (view) Author: malte Date: 2023-07-25.13:58:40
Pull request looks OK to merge for me. Regarding code changes triggered by what the silenced warnings are based on, I don't think accidental shadowing is necessary a problem, but we can of course merge changes that actually improve the code. (The num_variables example indeed looks pointless.)
msg11183 (view) Author: florian Date: 2023-07-25.11:27:57
I added a link to the PR that so far only removes ignores for warnings that do not trigger anymore and starts treating warnings as errors on Windows builds again.

I suggest that we decide if we want to fix any of the other issues and then either do that here, or create specific follow-up issues and close this one.
msg11182 (view) Author: florian Date: 2023-07-25.11:23:17
Here is the list of warnings we get for C4458(shadowing class members):

State::num_variables
    https://github.com/aibasel/downward/blob/main/src/search/task_proxy.h#L781

pdbs::PatternCollectionGeneratorMultiple::max_pdb_size 
pdbs::PatternCollectionGeneratorMultiple::rng
    https://github.com/aibasel/downward/blob/main/src/search/pdbs/pattern_collection_generator_multiple_random.cc#L33
    https://github.com/aibasel/downward/blob/main/src/search/pdbs/pattern_collection_generator_multiple_cegar.cc#L24

merge_and_shrink::MergeTreeNode::parent
    https://github.com/aibasel/downward/blob/main/src/search/merge_and_shrink/merge_tree.cc#L91

cegar::Node::var
cegar::Node::value
cegar::Node::left_child
cegar::Node::right_child
cegar::Node::value
    https://github.com/aibasel/downward/blob/main/src/search/cegar/refinement_hierarchy.h#L86
    https://github.com/aibasel/downward/blob/main/src/search/cegar/refinement_hierarchy.cc#L30

cg_heuristic::CGCache::depends_on
    https://github.com/aibasel/downward/blob/main/src/search/heuristics/cg_cache.cc#L78
  
enforced_hill_climbing_search::EnforcedHillClimbingSearch::evaluator
    https://github.com/aibasel/downward/blob/main/src/search/search_engines/enforced_hill_climbing_search.cc#L84
    https://github.com/aibasel/downward/blob/main/src/search/search_engines/enforced_hill_climbing_search.cc#L100
  
PruningMethod::task
    https://github.com/aibasel/downward/blob/main/src/search/pruning/stubborn_sets_ec.cc#L109
    https://github.com/aibasel/downward/blob/main/src/search/pruning/stubborn_sets_simple.cc#L14
    https://github.com/aibasel/downward/blob/main/src/search/pruning/stubborn_sets_atom_centric.cc#L18
    https://github.com/aibasel/downward/blob/main/src/search/pruning/limited_pruning.cc#L19
    https://github.com/aibasel/downward/blob/main/src/search/pruning/stubborn_sets.cc#L14
    https://github.com/aibasel/downward/blob/main/src/search/pruning/null_pruning_method.cc#L13

plugins::RawRegistry::subcategory_plugins
    https://github.com/aibasel/downward/blob/main/src/search/plugins/raw_registry.cc#L119
    https://github.com/aibasel/downward/blob/main/src/search/plugins/raw_registry.cc#L182
  
plugins::Feature::subcategory
plugins::Feature::title
plugins::CategoryPlugin::synopsis
plugins::SubcategoryPlugin::title
    https://github.com/aibasel/downward/blob/main/src/search/plugins/plugin.cc#L12
    https://github.com/aibasel/downward/blob/main/src/search/plugins/plugin.cc#L16
    https://github.com/aibasel/downward/blob/main/src/search/plugins/plugin.cc#L106
    https://github.com/aibasel/downward/blob/main/src/search/plugins/plugin.cc#L119
    https://github.com/aibasel/downward/blob/main/src/search/plugins/plugin.cc#L123

SearchEngine::plan
    https://github.com/aibasel/downward/blob/main/src/search/plugins/plugin.cc#L119
msg11181 (view) Author: florian Date: 2023-07-25.11:20:14
I ran our Github actions without the ignore statements. Surprisingly, all of this never caused the Github action to fail. A while ago, we removed flags "-Werror" and the windows equivalent "/WX" from the CMake files. For the Ubuntu build, we then explicitly export CXXFLAGS="-Werror" in the Github workflow, but for Windows we don't. I suggest we fix this.

I removed all ignore statements for warnings that never triggered. The remaining ignores fall in two categories: lossy conversions and shadowing.

The lossy conversions (C4244, C4267), I'd say are fine to ignore. In particular C4267 is about size_t to int which we do a lot. The other conversions are
  * from __int64 (integer literal, I think) to int, relaxation_heuristic::OpID, and relaxation_heuristic::PropID;
  * from int to _Ty (template arg?), char, and short; 
  * and from double and size_t to int.

The shadowing looks more like something we might want to fix in the code. Here are some examples for all types of warnings:

* C4458: declaration of 'num_variables' hides class member
    class State {
        int num_variables;
        void State::unpack() const {
            int num_variables = size();
            // ...
        }
    }
In this particular case, size() just returns the member num_variables. This looks completely unnecessary and we should fix it. There are other cases that are less obvious. I'll post them in a separate message.

* C4456: declaration hides previous local variable
    for (int i = 0; i < n1; ++i) {
        int j = 0;
        // do something with j
        for (int j = 0; j < n2; ++j) {
            // ...
        }
    }
Some of these look like potential problems, but we also heavily use this in the parser with trace blocks that all have the same name. We could give them different names but calling them all block emphasizes that their identity is not important and simplifies the code in my opinion. 
    {
        Traceblock block("list");
        parse_open_bracket();
        for (int i = 0; i < n; ++i) {
            Traceblock block("element " + i);
            parse_element();
        }
        parse_closing_bracket();
    }
Concrete cases are here:
https://github.com/aibasel/downward/blob/main/src/search/heuristics/domain_transition_graph.cc#L96 (origin)
https://github.com/aibasel/downward/blob/main/src/search/landmarks/landmark_factory_h_m.cc#L370 (pm_fluent)
https://github.com/aibasel/downward/blob/main/src/search/parser/abstract_syntax_tree.cc#L276 (block)


* C4459: declaration hides global declaration
    void f(const equivalence_relation::EquivalenceRelation &relation) {
        // ...
    }
Here 'relation' shadows 'std::relation'. We also get this for variables named 'predicate' and 'equivalence_relation'. All of these are not immediate problems for us, I'd say.
msg11167 (view) Author: malte Date: 2023-07-24.16:43:00
Sounds good. Is there an issue that this could be attached to, or another way we can give this info to the people that need to know it?
msg11165 (view) Author: florian Date: 2023-07-24.16:31:36
A lot of these warnings were for OSI and tree.hh, both of which we recently got rid off. I think it would be nice to at least remove the entries from our ignore-list that do not happen anymore. Maybe we could make this part of the CMake story, as removing lines from the CMake files would simplify it.
msg11159 (view) Author: malte Date: 2023-07-24.14:43:00
It has been a long time since we created this issue, and I'm not sure if this is still current and still a pain point. Closing this on the assumption that this either outdated or we don't care enough to change this. If you think we should work on this, speak up and we can reopen. But then we should also look into it.
msg4471 (view) Author: florian Date: 2015-07-26.17:10:38
Our compilation on Windows currently ignores the following warnings:

  /wd4800 # forcing value to bool
  /wd4512 # assignment operator could not be generated
  /wd4706 # assignment within conditional expression (in tree.hh)
  /wd4100 # unreferenced formal parameter (in OSI)
  /wd4127 # conditional expression is constant (in tree.hh and in our code)
  /wd4244 # conversion with possible loss of data
  /wd4702 # unreachable code
  /wd4239 # nonstandard extension used
  /wd4996 # function call with parameters that may be unsafe
  /wd4456 # declaration hides previous local declaration
  /wd4458 # declaration hides class member

For each warning, we should do one of the following
1) Fix the places that generate the warning
2) Wrap that part of the code in #pragma statements (e.g., for warnings in
tree.hh or OSI)
3) Decide to keep ignoring the warning
History
Date User Action Args
2023-07-25 16:51:40floriansetstatus: chatting -> resolved
messages: + msg11190
summary: PR: https://github.com/aibasel/downward/pull/160/files -> ~~PR: https://github.com/aibasel/downward/pull/160/files~~
2023-07-25 16:31:02floriansetmessages: + msg11187
2023-07-25 13:58:40maltesetmessages: + msg11184
2023-07-25 11:27:57floriansetmessages: + msg11183
summary: PR: https://github.com/aibasel/downward/pull/160/files
2023-07-25 11:23:17floriansetmessages: + msg11182
2023-07-25 11:20:14floriansetstatus: resolved -> chatting
messages: + msg11181
2023-07-24 16:43:00maltesetmessages: + msg11167
2023-07-24 16:31:36floriansetmessages: + msg11165
2023-07-24 14:43:00maltesetstatus: chatting -> resolved
messages: + msg11159
2015-07-26 17:17:12silvansetnosy: + silvan
2015-07-26 17:10:38floriancreate