Geometry/GEMGeometryBuilder/src/GEMGeometryBuilderFromDDD.cc const-cast fix #25913
Conversation
|
The code-checks are being triggered in jenkins. |
|
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-25913/8390
|
|
A new Pull Request was created by @watson-ij (Ian J. Watson) for master. It involves the following packages: Geometry/GEMGeometryBuilder @civanch, @Dr15Jones, @cvuosalo, @ianna, @kpedro88, @cmsbuild, @mdhildreth can you please review it and eventually sign? Thanks. cms-bot commands are listed here |
|
please test |
|
The tests are being triggered in jenkins. |
|
Comparison job queued. |
|
Comparison is ready Comparison Summary:
|
| @@ -66,6 +67,7 @@ GEMGeometryBuilderFromDDD::build( GEMGeometry& theGeometry, | |||
| if (detIdCh.layer() == 1){// only make superChambers when doing layer 1 | |||
| GEMSuperChamber *gemSuperChamber = buildSuperChamber(fv, detIdCh); | |||
| theGeometry.add(gemSuperChamber); | |||
| superChambers.push_back(gemSuperChamber); | |||
There was a problem hiding this comment.
It's a big dodgy to keep a list of writeable pointers after adding the super chambers to theGeometry. This technique works now, but future developers of the GEMGeometry class might assume that the GemSuperChamber objects stored in GEMGeometry cannot change since there is no interface that allows modification.
Perhaps the super chambers shouldn't be added to the GEMGeometry until after they are complete, but such an approach might have some side effects caused by changing the order of the objects stored in the GEMGeometry object.
Or a new method could be added to GEMGeometry:
const std::vector<GEMSuperChamber*>& GEMGeometry::superChambersWriteable();
to clearly allow writing to super chambers after they have been added.
This PR can go in as-is, but it would be good to consider whether this special pointer list is really the best approach.
There was a problem hiding this comment.
Okay, that's a good point. If we move this to after adding to the ring, we can avoid changing the superchambers after adding to theGeometry. I think the ordering should only make a difference in the GEMRing, but this isn't affected by this change.
There was a problem hiding this comment.
Adding the super chambers to theGeometry after they are modifed makes more sense. As long as there is no side effect from changing the order that the eta parts, GEM chambers, and super chambers are added, this approach is better.
|
+1 |
|
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-25913/8407
|
|
Pull request #25913 was updated. @civanch, @Dr15Jones, @cvuosalo, @ianna, @kpedro88, @cmsbuild, @mdhildreth can you please check and sign again. |
|
please test |
|
The tests are being triggered in jenkins. |
|
Comparison job queued. |
|
Comparison is ready Comparison Summary:
|
|
The comparison test found 3 differences with the recent change. Are they due to this PR? |
|
+upgrade |
|
@cvuosalo the differences are in logErrorHarvester from a PU workflow, this is usually spurious |
|
+1 |
cmsbuild
added
fully-signed
geometry-approved
and removed
geometry-pending
pending-signatures
labels
|
This pull request is fully signed and it will be integrated in one of the next master IBs (tests are also fine). This pull request will now be reviewed by the release team before it's merged. @davidlange6, @slava77, @smuzaffar, @fabiocos (and backports should be raised in the release meeting by the corresponding L2) |
|
+1 |
This PR is to fix a static analyzer error in the code above. The code was using a const_cast when building the GEM geometry. By storing the superchambers in a vector, we avoid the need to call the superchambers() function and therefore avoid the const cast.
@jshlee